Subject: [MSEC] Questions about draft-ietf-pim-sm-linklocal

From: William Atwood <[email-masked]>
Date: Wed, 18 Oct 2006 07:29:25 -0400

Since one of the most useful responses to draft-atwood-pim-sm-linklocal 
came from an MSEC group member who does not subscribe to the pim mailing 
list, I obtained permission to cross-post the message below to the MSEC 
mailing list.  Any comments from the MSEC list members will be most 
appreciated.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
As requested after the PIM WG meeting at IETF-66, we have issued
draft-ietf-pim-sm-linklocal-00, which considers the problem of securing
the link-local (router-to-router) messages in PIM-SM.  Our original
proposal (in draft-atwood-pim-sm-linklocal-01) was
1) to use the IPsec Authentication Header (AH) to provide
authentication, and
2) to use Security Association (SA) selection based on source address to
permit enabling replay protection.
In preparing this new draft, we have freely borrowed ideas (and text)
from RFC 4552 (Authentication/Confidentiality for OSPFv3).  (Thanks to
Bill Fenner for this pointer.)

We have four questions that we specifically want to ask the Working
Group members:
1) Is there an operational need for confidentiality as well as
authentication?  If so, we will adopt appropriate text from RFC 4552 and
recommend the use of ESP in addition to AH.
2) One reply to the posting of draft-atwood-pim-sm-linklocal strongly
suggested the use of automated group key management for a community of
PIM-SM routers.  The arguments were convincing to us.  Does anyone have
any observations on the utility of this?  Should it be mandatory (MUST),
or recommended (SHOULD), or optional (MAY)?
3) RFC 4601 states:
"IPsec [8] allows (but does not require) there to be different Security
Policy Databases (SPD) for each router interface.  If available, it may
be desirable to configure the Security Policy Database at a PIM router
such that all incoming and outgoing Join/Prune, Assert, and Hello
packets use a different SA for each incoming and outgoing interface."
The solution that we propose uses the source address as a selector, and
thus avoids the necessity of multiple SPDs.  For this reason, we did
_not_ adopt the text from RFC 4552 that requires the ability to choose a
specific SPD based on the interface.  Does anyone see any disadvantages
to this decision?  (NOTE: OSFPv3 speakers (RFC 4552) cannot rely on the
limited number (and distance) of peers that we will have with PIM-SM
link-local messages.)
4) Is it preferable to continue to use ALL_PIM_ROUTERS (with the
proposed new semantics for secured messages), or to define a new SSM
address to be used for exchanging the secured messages?

Of course, comments on any part of the document will be most welcome.

Bill Atwood
Salekul Islam

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Professor Emeritus                fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http: //www.cse.Concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec