Re: [Anima] [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

Michael Richardson <> Tue, 21 July 2020 14:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AD573A09DE; Tue, 21 Jul 2020 07:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AqdsqLpbuG_g; Tue, 21 Jul 2020 07:54:28 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C0653A09DD; Tue, 21 Jul 2020 07:54:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0B1938A1E; Tue, 21 Jul 2020 10:34:01 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id S53sxJWtEzh0; Tue, 21 Jul 2020 10:34:00 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id 2AF0E38A1A; Tue, 21 Jul 2020 10:34:00 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 6C3C03F; Tue, 21 Jul 2020 10:54:25 -0400 (EDT)
From: Michael Richardson <>
To: Tero Kivinen <>,,
In-Reply-To: <>
References: <> <0b8001d5ecad$79ce7ad0$6d6b7070$> <> <0c9e01d5ed4c$2353f5a0$69fbe0e0$> <> <> <24142.1592760359@localhost> <> <> <> <> <> <6871.1595023836@localhost> <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 21 Jul 2020 10:54:25 -0400
Message-ID: <21070.1595343265@localhost>
Archived-At: <>
Subject: Re: [Anima] [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jul 2020 14:54:31 -0000

Tero Kivinen <> wrote:
    >> I am not really following this discussion very well.
    >> I'm not sure if this is general advice or ACP specific advince.

    > This discussion was not ACP specific, this was just generic reasons
    > why CERTREQ etc are usuful in general. Anyways I think most ACP cases
    > do not need CERTREQ, but on the other hand there might be cases where
    > it is still useful there, and thats why I would hate to see profile
    > that forbits its use. I.e., it is fine to say in profile, that
    > CERTREQs might not be needed, but saying that they should/must not be
    > sent is bad idea.

I hope that at no point do we forbid the use of anything.
A peer might not expect it/do anything.
The important part is that we say what pieces we *do* require.
There is one more revision of ACP coming out on Monday, and I hope that is
the last one that the IESG will approve on the next telechat.

    >> In the case that you describe (RSA->ECDSA),  I think that we would sign TA1
    >> with TA2, or vice-versa. (probably one and then the other a month later).
    >> We can feed/update the trust anchors when certificates are renewed, or we can
    >> use draft-ietf-netconf-trust-anchors to change things (the advantages of
    >> having really good security for in-band management)

    > If you have proper management, then you can do almost instanteneous
    > changes, but CERTREQ allows you do do similar things even when you do
    > not have any kind of management system configuring devices, with much
    > longer overlaps in configuration.

I think that proper management will probably not be in revision 1 of products.
However, a killer-use-case for the ACP is for SDN control channels, so I
could be wrong.

    >> I prefer relatively short expiries for certificates in the ACP
    >> because <STAR reasons>. I think that all systems have to support
    >> both RSA and ECDSA for a big overlapping period. I don't think this
    >> is a problem.
    >> I think that there is not a problem having a RSA key (TA1) sign an
    >> ECDSA EE cert. I know that I've done it, but I know that some think
    >> it uncool.

    > Sometimes the problem is that there are devices there which do not
    > support ECDSA at all, which means you are stuck with RSA for both root
    > and EE for all devices. With CERTREQ some parts of the network can
    > start use full ECDSA TA and EE and still interoperate with those
    > devices which support both and get the "coolness" factor of not using
    > RSA at all :-)

I think that we say that we will tolerate RSA :-)
So you are right: there could be devices which do not do ECDSA on day one,
and in which case, you can't switch the keys at all.

    > Other similar cases comes when you merge authorization domains
    > together, i.e., two companies merge and they both had their own CAs
    > before, and not all devices support both CAs, so you need to pick
    > correct certificate one when talking to one or another device.

Yes, this is an important case.

    >> So, we've been forced to use otherName, and this will cause new code in some
    >> of the IKEv2 daemon that we need to use :-(

    > No, you are not forced to use anything. Your ID could be KEY_ID with

No, the ACP document has been forced to use otherName in it's
certificates. That's nothing to do with IPsec/IKEv2.
But, that that's what IKEv2 will have to deal with.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-