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

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 5 Aug 2015 15:45:24 +0000

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.

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:[email-masked]]
> Sent: Tuesday, May 26, 2015 11:10 AM
> To: Stephen Farrell <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Aug 2015 14:43:24 +0100

Hiya,

Sorry for the slow response,

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

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Aug 2015 09:47:20 -0700

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

---

From: William Atwood <[email-masked]>
Date: Wed, 12 Aug 2015 15:05:43 -0400

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.
>
> On Aug 12, 2015 6:43 AM, "Stephen Farrell" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >
>  >
>  > Hiya,
>  >
>  > >> From: Brian Haberman [mailto:[email-masked]
> <mailto:[email-masked]>]
>  > >> To: Stephen Farrell <[email-masked]
> <mailto:[email-masked]>>; The IESG <[email-masked]
> <mailto:[email-masked]>>
>  > >> Cc: [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished 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://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Aug 2015 20:13:33 +0100

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.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 12 Aug 2015 19:25:59 +0000

Stephen, Bill,

Thanks for clearing this!

Given that much of the details are already in RFC 5796, and we don't really have much deployment experiences, I'll leave the details out of 4601bis. I'll submit the proposed text that refers to 5796 right now.

Jeffrey

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, August 12, 2015 3:14 PM
> To: William Atwood <[email-masked]>; Stig Venaas
> <[email-masked]>
> Cc: Brian Haberman <[email-masked]>; draft-ietf-pim-
> [email-masked]; [email-masked]; Jeffrey (Zhaohui) Zhang
> <[email-masked]>; The IESG <[email-masked]>; [email-masked]
> >>  > >>>>    Securing the unicast messages can be achieved by the use of
> a
> >> normal