[I2nsf] question on ipsec YANG model

Christian Hopps <chopps@chopps.org> Thu, 09 July 2020 16:47 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692413A0D9D; Thu, 9 Jul 2020 09:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awWybyXPxCBH; Thu, 9 Jul 2020 09:47:01 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6E17E3A0D9A; Thu, 9 Jul 2020 09:46:58 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8BABF60F11; Thu, 9 Jul 2020 16:46:57 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_B62F6565-25A9-4BFE-9FE1-44D808D409C9"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <7885C779-7120-469F-A4FC-AADDA71E7474@chopps.org>
Date: Thu, 09 Jul 2020 12:46:56 -0400
Cc: Christian Hopps <chopps@chopps.org>, i2nsf@ietf.org
To: draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/6midn2MljMxXlcT9L68v_QV9cN4>
Subject: [I2nsf] question on ipsec YANG model
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 16:47:04 -0000

Hi,

We are looking at using the ipsec model defined in "draft-ietf-i2nsf-sdn-ipsec-flow-protection" for augmenting to support IPTFS (https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01). This isn't necessarily b/c we have an interest in SDN per-se, but just that it appears to be *the* available IPsec YANG model. :)

When we started to augment in our configuration and operations state we encountered some issues.

The biggest issue is that the IKE model does not have a SAD. This seems to be a fairly large omission.

For example the conn-entry in in the IKE model has a list of encryption algorithms and integrity algorithms etc.. these would be used to make a proposal to the remote IKE; however, eventually something is selected, and an IKE SA, and subsequent CHILD_SA) are created. These SAs will have the specific selected parameters as well as other operational state (e.g., packet and byte counters etc).

This SA operational state should be accessible in the YANG model. One obvious way to do this would be to re-use the ikeless SAD by moving it to ipsec-common.

The other smaller issue is how the IKE connection entry configuration uses an SPD entry (I think). When IKE actually initiates a connection there may be multiple SPD entries that are created in order to support, for example, an IPsec tunnel. I believe the SPD entry under conn-entry in the ipsec-ike model though is being used only to specify the policy for the child SA that will be created. All the actual SPD entries that are created due to an IKE connection being established (with the corresponding child SAs referenced by reqid for the PROTECT versions) should probably be accessible from YANG as well. Otherwise one cannot view things such as BYPASS policy that has been installed.

The most obvious fix here would be to move the SPD out of ipsec-ikeless and into ipsec-common.

This doesn't leave anything in ipsec-ikeless though. :)  It could be that the IKE created SAs and SPDs also should only be accessible as read-only (operational state), but that would probably have to be determined by the YANG server and not specified in the model if the SAD and SPD would be shared by both IKE and IKE-less operation.

Thoughts?

Thanks,
Chris.