Re: [pim] Stephen Farrell's Discuss on draft-ietf-pim-rfc4601bis-05: (with DISCUSS)

[Stephen Farrell <[e-mail]>]

Thanks Bill, now I (finally:-) get it. Sorry for being slow.

I think some or all of the text you wrote below would be a fine
addition to the security considerations of 4601bis.

But up to you folks to do that or not, I'll make that a comment
as I clear my discuss.

If there's interest and utility in reinvigorating that part of
karp (i.e. if it'd get used) I'd be happy to AD sponsor the
relevant draft if everyone thought that'd be a good plan.

Cheers,
S.


On 12/08/15 20:05, William Atwood wrote:
> Stephen,
> 
> Here is a brief description of what happens.  I hope that it responds to
> your needs.  Additional questions are welcome!
> 
> Link-local security for PIM
> 
> In Section 8 of RFC 5796, two arrangements are given, one using a single
> key for all communication on a subnet, and the other using a separate
> key/SA for each sending node.
> 
> In the first case, each router maintains two SAs, one for sending (SAo)
> and one for receiving (SAi).  The SA parameters for these SAs are
> identical, on all nodes in the subnet.  This case is easy to manage
> (adding or subtracting a router requires no change to existing routers
> on the subnet), but the vulnerability (if the key is compromised) is
> higher.
> 
> In the second case, each router maintains (n+1) SAs, one for sending,
> and one for each of its “n” peers on the subnet.  This case is more
> difficult to manage, but compromise of a key exposes only one router.
> 
> Manual keying involves visiting each router (physically, or using
> suitable remote access to the CLI) and installing the necessary entries
> to the SAD and the SPD.
> 
> No procedures are as yet standardized for automated keying.  Proposals
> were under development in the KARP working group
> (draft-hartman-karp-mrkmp, draft-tran-karp-mrmp) until KARP was closed.
>  These proposals were for the generation and distribution of a single
> key per subnet (i.e., the first case).
> 
> Non-link-local security for PIM
> 
> For the Register and Register-Stop messages, which are unicast, and not
> link-local, a unicast SA must be established between the router closest
> to the sender and the Rendezvous Point (RP). As mentioned in RFC 4601
> and RFC 5796, standard IPsec SAs will be used and any of the approaches
> permitted by IKE (or IKEv2) can be used to establish credentials.  So,
> both manual key/SA management and automated key/SA management are
> already available for this case.  The only issue is the distribution of
> the appropriate certification, but this is no more difficult than for
> any other case where IKE (or IKEv2) is appropriate.
> 
> Note that the number of required SAs is related to the number of senders
> (actually the number of access routers close to senders), not the number
> of receivers, for a particular multicast group.
> 
> SA count
> 
> Depending on the case chosen, a router will maintain 2 or (n+1) SAs for
> its link-local PIM traffic, where “n” is the number of peers on the subnet.
> 
> A sending access router will maintain one unicast SA for each group
> where it forwards packets to the RP.
> 
> An RP will maintain an SA for each group on each sending access router.
> 
> Deployment and Implementation
> 
> Although there is little deployment experience that I am aware of, the
> link-local security procedures specified in RFC 5796 have been
> implemented (and shown to interoperate) for two routers, one a hardware
> router from CISCO and the other a software router running XORP on Linux.
>  Since there is no dependence between PIM and IPsec, the
> “implementation” involved only installing the keys in the appropriate
> SAs (in the SAD), and specifying that traffic destined for 224.0.0.13
> should be protected (in the SPD).  Extending this to one or more
> additional routers should be simple; I just did not have access to any
> other products.
> 
> Details of the experiments performed are available, if they would be
> useful.
> 
>   Bill
> 
> 
> On 8/12/2015 12:47 PM, Stig Venaas wrote:
>> I'm adding Bill Atwood who is the shepherd of this document, and the
>> author of 5796. He can hopefully comment on the link-local aspect and
>> maybe the more general question.
>>
>> For unicast messages you need some association between routers that send
>> registers and the RP, and between C-RPs and the elected BSR.
>>
>> Stig
>>
>> On Aug 12, 2015 6:43 AM, "Stephen Farrell" <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>  >
>>  >
>>  > Hiya,
>>  >
>>  > Sorry for the slow response,
>>  >
>>  > On 05/08/15 16:45, Jeffrey (Zhaohui) Zhang wrote:
>>  > > Stephen, Brian,
>>  > >
>>  > > Based on my understanding of the discussions, I'm proposing the
>> following new text for section 6.3:
>>  > >
>>  > > 6.3.  Authentication
>>  > >
>>  > >    This document refers to RFC 5796 [8], which specifies
>> mechanisms to
>>  > >    authenticate PIM-SM link-local messages using the IP security
>>  > >    (IPsec) Encapsulating Security Payload (ESP) or (optionally) the
>>  > >    Authentication Header (AH). It also points out that
>> non-link-local
>>  > >    PIM-SM messages (i.e., Register and Register-Stop messages)
>> can be
>>  > >    secured by normal unicast IPsec Security Association (SA) between
>>  > >    two communicants.
>>  > >
>>  > > We have not posted a new version yet, but want to see if the above
>> is reasonable.
>>  >
>>  > So I'm not sure. I've looked back at the earlier mail a bit and
>>  > and at 5796.
>>  >
>>  > Can you describe to me how it's feasible to use IPsec like this
>>  > and not end up being insecure? If that can be done in a short
>>  > paragraph then including that paragraph here would seem like
>>  > the thing to do. (Or if the text needed is in 5796 and/or other
>>  > places then just pointing at those would be fine.)
>>  >
>>  > The particular issue that I'm not clear on is how key management
>>  > for those unicast SAs can scale and also how the manual key
>>  > management for link-local stuff works in practice.
>>  >
>>  > If might help if someone can point at an example setup for
>>  > PIM-SM that secures all the relevant messages and says which
>>  > nodes share what keys etc. I don't know if such a document
>>  > exists but if it did (in any accessible format) I think it'd
>>  > help me understand that this change is ok. Note: I'm not asking
>>  > that that be included in 4601bis, I just think it might help
>>  > the discussion along quicker.
>>  >
>>  > Thanks,
>>  > S.
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > >
>>  > > For comparison, the text in -05 revision is:
>>  > >
>>  > >    RFC 4601 mandates the use of IPsec to ensure authentication of
>> the
>>  > >    link-local messages in PIM-SM. The description of authentication
>>  > >    using IPsec has been removed due to lack of sufficient
>> implementation
>>  > >    and deployment experience. RFC 5796 [8] specifies mechanisms to
>>  > >    authenticate the PIM-SM link-local messages using the IP security
>>  > >    (IPsec) Encapsulating Security Payload (ESP) or (optionally) the
>>  > >    Authentication Header (AH). It specifies optional mechanisms to
>>  > >    provide confidentiality using the ESP. The reader is referred
>> to RFC
>>  > >    5796 [8] for detailed discussion of authentication using IPsec.
>>  > >
>>  > > Thanks!
>>  > > Jeffrey
>>  > >
>>  > >> -----Original Message-----
>>  > >> From: Brian Haberman [mailto:[e-mail]
>> <mailto:[e-mail]>]
>>  > >> Sent: Tuesday, May 26, 2015 11:10 AM
>>  > >> To: Stephen Farrell <[e-mail]
>> <mailto:[e-mail]>>; The IESG <[e-mail]
>> <mailto:[e-mail]>>
>>  > >> Cc: [e-mail]
>> <mailto:[e-mail]>; [e-mail]
>> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>>  > >> Subject: Re: [pim] Stephen Farrell's Discuss on
>> draft-ietf-pim-rfc4601bis-
>>  > >> 05: (with DISCUSS)
>>  > >>
>>  > >> Hi Stephen,
>>  > >>
>>  > >> On 5/26/15 10:59 AM, Stephen Farrell wrote:
>>  > >>>
>>  > >>>
>>  > >>> On 26/05/15 15:29, Brian Haberman wrote:
>>  > >>>> Hi Stephen,
>>  > >>>>
>>  > >>>> On 5/26/15 9:08 AM, Stephen Farrell wrote:
>>  > >>>>> Stephen Farrell has entered the following ballot position for
>>  > >>>>> draft-ietf-pim-rfc4601bis-05: Discuss
>>  > >>>>>
>>  > >>>>> When responding, please keep the subject line intact and reply
>> to all
>>  > >>>>> email addresses included in the To and CC lines. (Feel free
>> to cut
>>  > >> this
>>  > >>>>> introductory paragraph, however.)
>>  > >>>>>
>>  > >>>>>
>>  > >>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-
>>  > >> criteria.html
>>  > >>>>> for more information about IESG DISCUSS and COMMENT positions.
>>  > >>>>>
>>  > >>>>>
>>  > >>>>> The document, along with other ballot positions, can be found
>> here:
>>  > >>>>> https://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601bis/
>>  > >>>>>
>>  > >>>>>
>>  > >>>>>
>>  > >>>>>
>> ----------------------------------------------------------------------
>>  > >>>>> DISCUSS:
>>  > >>>>>
>> ----------------------------------------------------------------------
>>  > >>>>>
>>  > >>>>>
>>  > >>>>>
>>  > >>>>> 4601 used IPsec AH for it's MTI security. This removes that and
>>  > >>>>> points at 5796 which defines how to use ESP for link local
>>  > >>>>> addresses and with manual keying. That raises one technical
>>  > >>>>> question and two ickky process questions. The ickky process
>>  > >>>>> questions are probably best discussed between the IESG at least
>>  > >>>>> initially in case we don't need to bother the authors/wg with
>>  > >>>>> 'em.
>>  > >>>>>
>>  > >>>>> (1) I'd like to check that 5796 defines a way in which one can
>>  > >>>>> secure all PIM messages that are defined here in 4601bis (should
>>  > >>>>> one want to do that). If there are cases where PIM-SM can be
>>  > >>>>> used and where there is no well defined security then I think
>>  > >>>>> that would be a problem. And I think maybe there are such cases.
>>  > >>>>> Am I wrong? If not, then how does one secure those?
>>  > >>>>
>>  > >>>> 5796 focuses on the link-local messages (i.e., directly-connected
>>  > >>>> peers), but does say
>>  > >>>>
>>  > >>>>    Securing the unicast messages can be achieved by the use of a
>> normal
>>  > >>>>    unicast IPsec Security Association (SA) between the two
>> communicants.
>>  > >>>>
>>  > >>>> The above refers to the set of PIM messages that are not sent as
>>  > >>>> link-local.  My opinion is that this is sufficient given the
>> uses of
>>  > >> PIM
>>  > >>>> as defined in 4601.
>>  > >>>
>>  > >>> Hmm. So you're saying that the way to secure PIM-SM is to have
>> a set
>>  > >>> of unicast IPsec SAs that cover all of the routers in the MC
>> group?
>>  > >>> That seems a bit odd doesn't it?
>>  > >>
>>  > >> These are just PIM control messages (Register and Register-Stop)
>> and
>>  > >> what you describe is exactly what you would have to do in the
>> case of
>>  > >> 4601.  All other PIM control messages are covered by 5796.  So,
>> No, this
>>  > >> does not seem odd to me.
>>  > >>
>>  > >>>
>>  > >>>>> (2) Is it ok for an IS to depend on a PS for it's MTI security
>>  > >>>>> mechanism? (I think it is, but yeah, someone else might not.)
>>  > >>>>
>>  > >>>> I don't see why not.
>>  > >>>
>>  > >>> I agree I think, but would like to check if that's an IESG opinion
>>  > >>> or just you and me. (Can be done on the call.)
>>  > >>
>>  > >> Sounds good.
>>  > >>
>>  > >>>
>>  > >>>>
>>  > >>>>>
>>  > >>>>> (3) Is it ok for an IS to not conform to BCP107? (I think it
>>  > >>>>> depends, and I'm not sure in this case.)
>>  > >>>>
>>  > >>>> I am not sure how BCP 107 relates since it discusses
>> Guidelines for
>>  > >>>> Cryptographic Key Management and the crypto stuff is now
>> referred to
>>  > >> via
>>  > >>>> 5796.
>>  > >>>
>>  > >>> Abstract of 5796 says it only supports manual keying. BCP107 says
>>  > >>> you have to define automated keying (with some exceptions into
>> which
>>  > >>> PIM-SM doesn't fit). Those do seem to be in conflict I think.
>>  > >>
>>  > >> Right, but 5796 is not going to IS.
>>  > >>
>>  > >> Regards,
>>  > >> Brian
>>  > >>
>>  > >
>>
>