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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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