Subject: [pim] Reminder: pim wg last call on draft-ietf-pim-lasthop-threats-01.txt

From: Stig Venaas <[email-masked]>
Date: Thu, 06 Sep 2007 16:24:21 +0200

There have been absolutely no responses so far, no support, no
objections or anything.  We can not advance this document unless there
is at least some support for it. If you believe this document is useful
and looks good, please speak up. If you think the document is not useful
or could be improved, please speak up as well.

The last call ends on Monday, please respond to the list by then if you
care whether this draft is published or not.

Stig

Stig Venaas wrote:
> This message announces a pim wg last call on "Last-hop Threats to
> Protocol Independent Multicast (PIM)"
> <draft-ietf-pim-lasthop-threats-01.txt>.  The last call will conclude at
> 1700EDT on Mon, 2007-09-10.
> 
> Please respond to this wg last call.  If you support acceptance of the
> document without change, respond with a simple acknowledgment, so that
> support for the document can be assessed.  Lack of discussion does not
> represent positive support.  If there is no expression of support for
> acceptance during the wg last call, the document will not be advanced
> to the IESG.
> 
> draft-ietf-pim-lasthop-threats-01.txt analysis last-hop security threats
> to the PIM routing protocol.  It is available at
> http://www.ietf.org/internet-drafts/draft-ietf-pim-lasthop-threats-01.txt
> 
> Stig
> 
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim

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

---

From: John Zwiebel <[email-masked]>
Date: Thu, 6 Sep 2007 12:49:36 -0700

> care whether this draft is published or not.

OK...

How is it a 'last-hop' threat to send pim register messages?
They are only sent by the 'first-hop'.

How is it that only 'last-hop' links can be threatened by
unauthorized PIM neighbors?

How is it that a router that accepts messages from non-neighbors
can only be on the last hop?

I'm surprised to discover that PIM asserts only happen on the 'last- 
hop'.

Where is the threat for bidir DF elections?

---

From: Pekka Savola <[email-masked]>
Date: Fri, 7 Sep 2007 09:28:01 +0300 (EEST)

> can only be on the last hop?

Maybe these are due to a terminology issue -- I'd like to use a word 
that applies both to last hop and first hop (from a sending/receiving 
host's perspective).  Do you (or anyone else) have suggestions?

> I'm surprised to discover that PIM asserts only happen on the 'last-hop'.

This too may be a terminology issue and/or applicability depending on 
whether you implied "also on first-hop" or "on any hop".  Issues on 
links which do not have hosts attached are out of scope (with 
implication that this is what RFC 4609 was supposed to address) and as 
such "on any hop" is too generic for the draft.

> Where is the threat for bidir DF elections?

Good point.  Would you or someone else be willing to contribute a 
paragraph or two on this?  I do not understand bidir-PIM well enough 
myself.

Are there any other changes required to address bidir-PIM 
specificities? (I believe the document has not been scrutinized from 
that perspective..)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Stig Venaas <[email-masked]>
Date: Fri, 07 Sep 2007 08:54:35 +0200

> host's perspective).  Do you (or anyone else) have suggestions?

I was also wondering a bit whether last-hop was the best terminology,
it is more like "edge/leaf" network threats? Or it is really threats on
any link where you allow non-trusted parties to connect. I am not sure
what is best either, but last-hop has a particular meaning when talking
about multicast which isn't quite as you use it Pekka.
> such "on any hop" is too generic for the draft.

This might be a reason to somehow talk about non-trusted links or
something instead of edge/leaf networks? I think the issues you describe
apply to any place in the network where a non-trusted host is connected,
but perhaps also non-trusted routers?

> Are there any other changes required to address bidir-PIM specificities?
> (I believe the document has not been scrutinized from that perspective..)
> 
I'll have a look at this now. Although my understanding of bidir is not
as good as some others, I might be able to help.

Stig

---

From: Prashant Jhingran <[email-masked]>
Date: Fri, 07 Sep 2007 13:11:12 +0530

Hi Stig,

Over all the draft looks good in addressing edge/leaf
issues, in fact all scenarios where malicious hosts/routers
exist.

I have a comment on IP Filtering (Section 4.3.  IP Filtering
PIM Messages) mechanism.
" 2.  Filter out all PIM messages at configured host ports
on Ethernet switches instead of doing it on the routers. "

Its good to block IP protocol 103 (all PIM messages) on
Ethernet switches also but switches might not filter with
such a granularity (most of them), therefore in case if such
filtering is not implemented then the draft can recommend
administrators to enable filtering on the basis of
ALL-PIM-ROUTERS address. This would filter our all PIM
multicast messages. 

However in order to filter unicast messages viz. Register &
Register Stop, the routers need to perform filtering as
suggested in the draft.

Regards,
Prashant Jhingran

Huawei Technologies
+91 - 80 - 41117676 Ext - 1458
+91 - 9448927814

============================================
" Peace means an undivided mind; OM SHANTI !"
 - www.artoflivingresearch.org 
===========================================

This e-mail and attachments contain confidential information
from HUAWEI, which is intended only for the person or entity
whose address is listed above. Any use of the information
contained herein in any way (including, but not limited to,
total or partial disclosure, reproduction, or dissemination)
by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete
it!

===================EOM===========================

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 7:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: [pim] Reminder: pim wg last call
ondraft-ietf-pim-lasthop-threats-01.txt

There have been absolutely no responses so far, no support,
no
objections or anything.  We can not advance this document
unless there
is at least some support for it. If you believe this
document is useful
and looks good, please speak up. If you think the document
is not useful
or could be improved, please speak up as well.

The last call ends on Monday, please respond to the list by
then if you
care whether this draft is published or not.

Stig

> to the PIM routing protocol.  It is available at
http://www.ietf.org/internet-drafts/draft-ietf-pim-lasthop-t
hreats-01.txt

---

From: Stig Venaas <[email-masked]>
Date: Fri, 07 Sep 2007 15:48:10 +0200

Stig Venaas wrote:
[...]
> as good as some others, I might be able to help.

There are several bidir threats related to DF election as explained in
the security considerations of the bidir draft. A bad PIM neighbor
(possibly a host that has sent hello messages) can do the following
things:

o Pretend to have very good metrics for the RPA and make sure it wins
  the DF election for that RPA. It might wait to see DF offers for RPAs
  and always send its own offers with better metrics to make itself the
  DF for any RPA. Doing this it can inspect and/or modify packets and
  also create a black hole. This is similar to the DR/Assert attacks.
  If it becomes the DF no other router will attempt to forward
  downstream packets onto the link, and no other router will forward
  packets from the link upstream to the RPL.

o Another possibility is to forge messages claiming that another router
  is the DF for the RPA. All routers on the link except for the one
  being "impersonated" may believe this. The one being impersonated may
  restart the election. It is not clear to me how useful this attack is.

o Finally, by regularly sending offer messages one can prevent the DF
  election process from converging, causing no router to become the DF.

Stig

---

From: John Zwiebel <[email-masked]>
Date: Fri, 7 Sep 2007 13:12:15 -0700

>   restart the election. It is not clear to me how useful this  

If one can somehow get two routers to believe they are the DF
you can quickly melt down the network as you end up with a
spanning tree storm.

I won't pretend that I have any idea how this might happen though.

---

From: ycai <[email-masked]>
Date: Fri, 07 Sep 2007 16:43:30 -0700

If one has connections to two subnets and wants to screw up bidir
forwarding,  it doesn't have to send any protocol packets.  All it needs to
do is to forward a packet from one subnet to another...

If it has just one interface,  the attack would be sending offer messages
with the lowest metric possible.

There is no need to forge the identity of the DF to mess up bidir.

-- 
Yiqun

---

From: John Zwiebel <[email-masked]>
Date: Fri, 7 Sep 2007 17:03:19 -0700

> with the lowest metric possible.

Which would deny upstream forwarding, something that has to be
in place to create a forwarding loop.

> There is no need to forge the identity of the DF to mess up bidir.

Absolutely, it isn't required, but that doesn't rule it out as
a possible attack vector.

Try this one, the DF is properly elected, but the attacker sends
(*,G) joins to the DR instead of the DF, now the DR forwards downstream,
and the DF sends them upstream.  So in this case it isn't the DF
election itself, but an incongruence between DR/DF/attacker on which  
router
is the DF and which router receives a (*,G) join and how that (DR, in
this case) handles receipt of a (*,G) join when it isn't a DF.

(somebody may not have tested for this on their OS, so, the 'attack' is
just a huge bug.)

           up
      -+------------+-
       |     >      |       packet goes around and around.
      DF ^       v DR
       |     <      |
      -+-----+------+-
             |
          attacker

---

From: Stig Venaas <[email-masked]>
Date: Sat, 08 Sep 2007 12:15:44 +0200

>> with the lowest metric possible.

Yes, this is the first case I noted.
> a possible attack vector.

Right, I am wondering what it would buy you over the other simpler
attacks though.
> (*,G) joins to the DR instead of the DF, now the DR forwards downstream,

My understanding is that no router, including the DR, should forward
downstream unless it is the DF on the downstream link. So I don't see
the problem here.

One interesting attack which is noted in the bidir draft is making two
routers on the same link both believe they are DFs, this seems hard to
achieve though.

Stig

> election itself, but an incongruence between DR/DF/attacker on which router

---

From: John Zwiebel <[email-masked]>
Date: Mon, 10 Sep 2007 11:11:59 -0700

> Right, I am wondering what it would buy you over the other simpler

Because the simpler attacks have been protected against?

> downstream unless it is the DF on the downstream link. So I don't see

"not suppose to" is the operative point.  Note that what I was proposing
here was the DF is a bidir router and the DR is not.

Again, a more complicated attack, but if you've fixed everyting else...

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Sep 2007 10:22:12 +0300 (EEST)

Hi,

> Register Stop, the routers need to perform filtering as

That's true, though I'd rather not add that as a recommendation 
because that's not effective as PIM protocol filtering and it doesn't 
buy you much on top of passive mode pim.  Further this might be a 
problem if another address were to be used later or if implementations 
processed PIM packets which were destined to their unicast addresses 
(probable).

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Sep 2007 11:30:48 +0300 (EEST)

> There is no need to forge the identity of the DF to mess up bidir.

I was revising the on-link document with Stig when I noticed two 
issues with bidir-PIM which likely require some resolution or at least 
clarification whether these are issues or not.

1. If the description above and BIDIR's forwarding algorithm is
    correct [1], DF doesn't do any RPF check from its on-link sources.
    That would allow spoofing the source address of packets, and as
    ycai writes could probably also lead to forwarding loops.  This
    goes against the basic principle that multicast routing protocols
    take care of the correctness of the source address.

2. DF election packets from non-PIM neighbors.  I'm unable to find
    text in the BIDIR-PIM spec that would give an indication what to do
    when a router receives a BIDIR election packet from a non-neighbor.

    This is similar to receiving PIM join/prune messages from
    non-neighbors, and the practice should be disallowed (IMHO).

    Is there any reason to accept DF election packets prior to PIM
    neighbor establishment?

[1]
    First we check to see whether the packet should be accepted based on
    TIB state and the interface that the packet arrived on.  A packet is
    accepted if it arrives on the RPF interface to reach the RPA
    (downstream traveling packet) or if the router is the DF on the
    interface the packet arrives (upstream traveling packet).

    If the packet should be forwarded, we build an outgoing interface
    list for the packet.

    Finally, we remove the incoming interface from the outgoing interface
    list we've created, and if the resulting outgoing interface list is
    not empty, we forward the packet out of those interfaces.

    On receipt of data to G on interface iif:
     if( iif == RPF_interface(RPA) || I_am_DF(RPA,iif) ) {
        oiflist = olist(G) (-) iif
        forward packet on all interfaces in oiflist
     }

---

From: Stig Venaas <[email-masked]>
Date: Tue, 25 Sep 2007 13:35:10 +0200

Pekka Savola wrote:
> I was revising the on-link document with Stig when I noticed two issues
> with bidir-PIM which likely require some resolution or at least

I've always assumed that you would still do per data packet source
RPF check, but after the mails on the list, discussion with Pekka and
careful reading of the draft it might appear that the intention is not
to do RPF on the data packet source address. I believe the draft at
least needs to say clearly what the behavior is. As Pekka says, it is a
dramatic change from the behavior of other multicast protocols if there
is no RPF. If there is no RPF check the security considerations really
need to include a big warning.

>    Is there any reason to accept DF election packets prior to PIM

This is clarified in 5.2:

   A BIDIR-PIM router SHOULD provide an option to limit the set of
   neighbors from which it will accept Join/Prune, Assert, and DF-
   election messages.  Either static configuration of IP addresses or an
   IPsec security association may be used.  Furthermore, a PIM router
   SHOULD NOT accept protocol messages from a router from which it has
   not yet received a valid Hello message.

This might be sufficient and we should do at most minimal changes. But
would it be good to point out that BIDIR messages should not be accepted
unless it comes from a BIDIR capable neighbor?

Stig

---

From: ycai <[email-masked]>
Date: Tue, 25 Sep 2007 17:18:53 -0700

> need to include a big warning.

I'm not aware of anyone does per packet RPF check against the sources.

Note that the DF is elected based on "upstream metric".  If there is
asymmetrical metric,  this RPF check may always fail at intermediate hops.
And I'm not sure how useful it is to only "RPF" packets that are coming from
directly connected sources.

> unless it comes from a BIDIR capable neighbor?

Certainly.  In fact,  the entire DF election/forwarding mechanism should be
stopped if there are non bidir-capable PIM routers.

-- 
Yiqun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Sep 2007 07:48:39 +0300 (EEST)

> I'm not aware of anyone does per packet RPF check against the sources.

Does this refer to implementations when BIDIR-PIM is enabled? 
Specifically, you were not saying that PIM-SM implementations also 
don't do this check?

> asymmetrical metric,  this RPF check may always fail at intermediate hops.

So I guess this is a BIDIR corner case which wasn't addressed, but 
rather the decision was to accept packets from non-bidirectional 
forwarding trees.

> And I'm not sure how useful it is to only "RPF" packets that are 
> coming from directly connected sources.

Is it easy to distinguish directly connected sources, in other words, 
would it be easy to add an RPF check on such interfaces?

That's the multicast equivalent of uRPF which has been assumed by 
operators from day one.  If it isn't done, we must make it loud and 
clear that uRPF must be applied to multicast traffic as well.  I'm 
pretty sure IETF wouldn't be popular if that approach is chosen.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 26 Sep 2007 15:16:59 +0200

> directly connected sources.

I suggest that at the end of 3.3 (forwarding rules, above 3.3.1) add a
sentence stating that no RPF check is performed on the data packet
source addresses. And also in the security considerations add a
sentence stating that since no RPF check is performed on the source
addresses, and hence BIDIR does not help prevent source address
spoofing, as opposed to other multicast routing protocols like PIM-SM.

> stopped if there are non bidir-capable PIM routers.

Right, this sounds like the safest thing to do (with John Z's example of
possible looping with a non-BIDIR DR in mind).

It is bad to try to change the specification this late (now in AUTH48),
but I think it's worth it in this case.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 27 Sep 2007 09:54:19 +0200

> asymmetrical metric,  this RPF check may always fail at intermediate hops.

Right. As I've been kindly reminded you cannot do source RPF for a
shared tree, hence it should not have been a surprise that BIDIR
doesn't do it. I'm embarrassed I didn't think of that earlier.

Stig

---

From: ycai <[email-masked]>
Date: Thu, 27 Sep 2007 19:24:09 -0700

Stig, 

Do you still think we need to change the spec?  I'm not sure we do.

-- 
Yiqun

---

From: ycai <[email-masked]>
Date: Thu, 27 Sep 2007 19:24:09 -0700

Stig, 

-- 
Yiqun

---

From: ycai <[email-masked]>
Date: Thu, 27 Sep 2007 19:23:16 -0700

> Specifically, you were not saying that PIM-SM implementations also

I'm not sure if that matters.

RPF check (for multicast packets) can only be done after a corresponding
multicast routing table entry, (*,G), (s,G), or fancier (*,G/mask), has been
located.  And once the entry is located, the mode of the group and
forwarding rule is known.

> rather the decision was to accept packets from non-bidirectional

I'm not aware of that decision.  I don't think it is documented anywhere
(but I'm not a good reader by any means).

If one performs bidir forwarding rules, namely, upstream forwarding by a DF,
on a lan where there are non-bidir capable routers,  loops may occur.

> would it be easy to add an RPF check on such interfaces?

You will get different answers from different people so I will refrain from
making a comment here.

> pretty sure IETF wouldn't be popular if that approach is chosen.

I don't know how you can mandate uRPF (unicast RPF) for multicast traffic.
uRPF is based on forwarding table entries for unicast routes.  Multicast RPF
check is done based on information stored in entries in the multicast
forwarding table. I don't see they are comparable unless I'm missing
something.

-- 
Yiqun

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Sep 2007 10:21:07 +0300 (EEST)

> forwarding table. I don't see they are comparable unless I'm missing

Well, at least some vendors implement uRPF as an RPF check.  It 
applies to both unicast and multicast.  Because such uRPF is typically 
applied only on stub interfaces, source addresses need to be correct 
in both unicast and multicast packets, so there is no problem -- in 
practise.

The difference emerges if you were to apply such RPF check for 
multicast forwarding between routers especially around the RP.

---

From: Stig Venaas <[email-masked]>
Date: Fri, 28 Sep 2007 09:20:41 +0200

> Do you still think we need to change the spec?  I'm not sure we do.

Right. If it had been earlier in the process I would have wanted some
minor changes, but since we are in AUTH48 and changes should be avoided
... My opinion is now that we should go ahead. The spec will hopefully
be out very soon now.

Stig