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

[Stephen Farrell <[e-mail]>]

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