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

[Paul Wouters <[e-mail]>]

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