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

From: JW Atwood <[email-masked]>
Date: Mon, 16 Oct 2006 17:51:53 -0400

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

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 17 Oct 2006 09:37:26 +0300 (EEST)

Hi,

BTW, the draft doesn't yet describe what the SPDs would look like in 
practice.  You will also need to describe what PAD entries (assuming 
automated key management) will look like. 
draft-ietf-v6ops-ipsec-tunnels-03.txt might give some ideas.

Inline,

> recommend the use of ESP in addition to AH.

I doubt so, and if so, maybe it would be better to use only ESP 
(because that can provide payload integrity as well), as the benefit 
of ESP+AH might not be worth it.

> 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)?

If this document aims to be on standards track, this is probably 
needed, see Security ADs review of PIM-SM spec:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=41358

I'd say that a automatic key management mechanism should be a MUST if 
this approach is adopted.  The number of PIM routers is high enough 
that no one will want to set up SAs manually.

> 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.)

I suspect you will require interface-specific SPDs.  This is because 
with both v4 (unnumbered interface = packet sent with 0.0.0.0 source 
address AFAIR) and v6 (link-local address) multiple interfaces could 
use the same address.

Using the address is sufficient for cases where you'll need to use 
domain-wide reachable addresses (e.g., for Register/Register-Stop).

> 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?

I haven't thought this much, but given that non-IPsec traffic is 
protocol 103 and IPsec is either protocol 50 or 51, it isn't possible 
to confuse the two kinds of packets even if they'd use the same 
address.  Hence using the same address might be preferable.

-- 
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: Tue, 17 Oct 2006 09:24:20 +0200

Pekka Savola wrote:
[...]
>> 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)?

If some automated management for a community of PIM-SM routers is 
considered, then I think it should also take into account how to use 
this for non-link-local PIM messages (register and register stop). Or
maybe it's obvious how to do that?

[...]
> protocol 103 and IPsec is either protocol 50 or 51, it isn't possible to 
> confuse the two kinds of packets even if they'd use the same address.  
> Hence using the same address might be preferable.
> 

Using same sounds reasonable to me. I don't see the benefit of doing SSM
here. Having to do a join per neighbour just adds complexity. Apart from
how to perform the join, I don't see any difference between link-local
ASM and SSM. You would do exactly the same processing and can have the 
same SAs with or without SSM.

Stig