Subject: Comment: PIm Sparse Mode to Proposed

From: Sam Hartman <[email-masked]>
Date: Thu, 27 Oct 2005 11:19:19 -0400 (EDT)

[IETf, the following is a ballot comment on the PIM Sparse Mode
document which is before the IESG today.  This is not a discuss: I am
not holding the document until this issue is fixed.  I do not expect
the authors to address my comment, but I do ask the community to
consider the issue.]

This comment is not a discuss, but I am certainly not thrilled with
the current situation.  This document does not define a mandatory to
implement security mechanism.  It does tell network administrators how
to use IPsec to secure PIM.

That's not really enough for several reasons.  First, it does not
require the necessary features of IPsec be implemented along side PIM.
Second, it provides a reasonably bad user experience: the user has to
use a general mechanism that doesn't know about PIM not one that knows
about PIM.  So the user has to encode all the information about PIM
and its traffic flows for the general mechanism.  Unfortunately it is
probably not as simple as having vendors provide easy configuration
tools.  While a vendor could do that for their own products, the user
has enough flexibility in how they configure things that such a vendor
would not be guaranteed to work with other products or arbitrary
sites.  

So I'm not going to block this document.  However we must do better in
the future.  The primary purpose of this comment is to say that I'm
not happy with this direction and that the fact that this document
passes IESG review may not be used as a justification that future work
should be allowed through.

I would certainly hold work started today to a higher standard.  This
document would also get a discuss because it has no mandatory
automated key management if it were new work.

We will have to work on what scale is appropriate for work already in
progress.

On a more positive note, I'd like to thank the authors for a really
well written document.  I wish all the specs I had to review were of
this quality.

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Oct 2005 22:57:20 +0300 (EEST)

I'll add Cc: to PIM wg.

> to use IPsec to secure PIM.
...
> should be allowed through.

In my opinion, there seem to be two main classes of PIM 
vulnerabilities:

  1) those relating to multicast routing infrastructures (between 
routers); these have been described in:
draft-ietf-mboned-mroutesec-04.txt (in rfc-ed queue, waiting for the 
pim spec)

  2) those relating to the interaction of users/apps and multicast 
routing infrastructures; these have been described in (expired) draft:
http://netcore.fi/pekkas/ietf/draft-savola-pim-lasthop-threats-01.txt

(this has been presented and discussed in PIM WG, with decision to 
wait and see until the PIM spec is reviewed/approved by the IESG).

While there is not clear easy-to-use, robust security mechanism for 
1), one has been described for 2) in those scenarios where there is 
only one multicast router on the LAN.

...

I hope this clarifies what I believe is the PIM protocol threat 
"landscape", while the mitigation mechanisms may not be sufficient in 
all the cases.

Unfortunately, it seems neither of these drafts is referred in the PIM 
spec.

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