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

[Pekka Savola <[e-mail]>]

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,

On Mon, 16 Oct 2006, JW Atwood wrote:
> 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.

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.

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

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.

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

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

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