Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-ospfv3-srv6-extensions-12: (with DISCUSS)

[Ketan Talaulikar <[e-mail]>]

Hi Paul,

I have posted an update with text changes to address your concerns:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-13

I've tried to steer clear of specifics/details that are outside the scope
of this document. Can you please let me know if this works and if not
provide some suggestions?

Thanks,
Ketan


On Thu, Jun 8, 2023 at 6:33 AM Paul Wouters <[e-mail]> wrote:

>
> On Wed, Jun 7, 2023 at 2:17 AM Ketan Talaulikar <[e-mail]>
> wrote:
>
>> Hi Paul,
>>
>> This document is specifying extensions for OSPFv3 for SRv6. Any
>> discussion related to changing or improving security for base OSPFv3
>> protocol would be outside the scope of this document.
>>
>
> I agree, but then perhaps the Security Considerations could indicate that
> more clearly. Right now it is making claims that if you want to use this
> draft (so this extension) securely, go look at these IKEv1 things. I am
> fine with an extension that uses whatever the core and other extensions use
> for security. (and that hopefully someone will look at upgrading those
> oudated security methods references in the core protocol in the near
> future).
>
>
>> Regarding IPSec and IKE, FWIW, lately I have seen operators requesting
>> RFC7166 (OSPFv3 Auth Trailer) over the IPSec method of RFC5340.
>>
>
> 7166 does seem like a better method than the 4552 Manual Keying for IPsec
> method. Please consider giving that recommendation a bit
> more weight than 4552.
>
>
>>
>> That said, can you please check on my response and proposed text changes
>> to Roman and let me know if those work for you?
>>
>> https://mailarchive.ietf.org/arch/msg/lsr/51bzckFrw_YCtIGiA1BikDVhyoU/
>>
>
> As that is still recommending 4552 equally to 7166, I think it is a bit
> problematic. As per RFC 8221:
> https://datatracker.ietf.org/doc/html/rfc8221#section-3
>
>    Manual keying SHOULD NOT be used, as it is inherently dangerous.
>    Without any secure keying protocol, such as IKE, IPsec does not offer
>    Perfect Forward Secrecy (PFS) protection; there is no entity to
>    ensure the refreshing of session keys, the tracking of Security
>    Parameter Index (SPI) uniqueness, and the single use of nonces,
>    Initialization Vectors (IVs), and counters.  This document was
>    written for deploying ESP/AH using IKE [RFC7296 <https://datatracker.ietf.org/doc/html/rfc7296>] and assumes that
>    keying happens using IKEv2 or higher.
>
>    If manual keying is used regardless, Counter Mode algorithms such as
>    ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM, and ENCR_CHACHA20_POLY1305
>    MUST NOT be used, as it is incompatible with a secure and persistent
>    handling of the counter (as explained in the Security Considerations
>    section of [RFC3686 <https://datatracker.ietf.org/doc/html/rfc3686>]).  This particularly applies to IoT devices that
>    have no state across reboots.  At the time of writing, ENCR_AES_CBC
>    is the only mandatory-to-implement encryption algorithm suitable for
>    manual keying.
>
>
> If 4552 is mentioned, perhaps caveat it with a reference to RFC 8221
> Section 3 ?
>
> Paul
>
> On Wed, Jun 7, 2023 at 7:13 AM Paul Wouters via Datatracker <
>> [e-mail]> wrote:
>>
>>> Paul Wouters has entered the following ballot position for
>>> draft-ietf-lsr-ospfv3-srv6-extensions-12: 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/about/groups/iesg/statements/handling-ballot-positions/
>>> for more information about how to handle DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> I have a DISCUSS similar to Roman:
>>>
>>> Existing security extensions as described in [RFC5340] and [RFC8362]
>>> apply to
>>> these SRv6 extensions. While OSPFv3 is under a single administrative
>>> domain,
>>> there can be deployments where potential attackers have access to one or
>>> more
>>> networks in the OSPFv3 routing domain. In these deployments, stronger
>>> authentication mechanisms such as those specified in [RFC4552] or
>>> [RFC7166]
>>> SHOULD be used.
>>>
>>> RFC5340 does say to use IPsec, but because of the "group" setting, IKE
>>> could
>>> not be used (I guess it pre-dates or didn't want to use Group DOI (GDOI)
>>> RFC3547 and Group Secure Association Key Management Protocol (GSAKMP)
>>> RFC4535).
>>> But RFC 4552 is recommending IPsec with manual keying, which is no longer
>>> really possible with AEAD ciphers (eg AES-GCM, which you would want to
>>> use for
>>> performance). It does state:
>>>
>>>    Future specifications can explore the usage of protocols like
>>>    Kerberized Internet Negotiation of Keys/Group Secure Association Key
>>>    Management Protocol (KINK/GSAKMP) when they are widely available.
>>>
>>> But I don't think KINK/GSAKMP became widely available. GDOI has seen
>>> some but
>>> not much implementation.
>>>
>>> Furthermore, RFC4535 is also a (not widely implemented) IKEv1 extension.
>>> This
>>> cannot be recommended anymore because IKEv1 itself is obsolete (see
>>> RFC9395)
>>>
>>> Updated advise would be to use draft-ietf-ipsecme-g-ikev2 "Group Key
>>> Management
>>> using IKEv2, but again we don't know yet if this will be widely
>>> available. That
>>> puts us back at "use manual keying or this soon to hopefully be
>>> available IKEv2
>>> RFC", except that with AEADs, we also cannot recommend manual keying
>>> anymore.
>>>
>>> I am not sure what to recommend as text here. Removing all IKEv1
>>> references and
>>> putting draft-ietf-ipsecme-g-ikev2 there and saying manual keying MUST
>>> NOT be
>>> used is not a good security recommendation either.
>>>
>>>
>>>
>>>
>>>
>>>