IETF Logo Mail Archive

Re: [IPsec] ESP Signally to higher layers

Christian Hopps <chopps@chopps.org> Sat, 21 May 2022 00:35 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE64EC237D17 for <ipsec@ietfa.amsl.com>; Fri, 20 May 2022 17:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKEdyf5_lGpq for <ipsec@ietfa.amsl.com>; Fri, 20 May 2022 17:35:38 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 246A3C237D15 for <ipsec@ietf.org>; Fri, 20 May 2022 17:35:38 -0700 (PDT)
Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8004F7D065; Sat, 21 May 2022 00:35:37 +0000 (UTC)
References: <76129f8a-9287-e19d-ec32-5c743a7afdf2@htt-consult.com>
User-agent: mu4e 1.7.13; emacs 28.0.92
From: Christian Hopps <chopps@chopps.org>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Cc: IPsecME WG <ipsec@ietf.org>
Date: Fri, 20 May 2022 20:27:54 -0400
In-reply-to: <76129f8a-9287-e19d-ec32-5c743a7afdf2@htt-consult.com>
Message-ID: <m24k1jn2nb.fsf@ja.int.chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Wsul9SBfCnZ2UH4YEFpDQqZudOg>
Subject: Re: [IPsec] ESP Signally to higher layers
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 May 2022 00:35:41 -0000

Robert Moskowitz <rgm-sec@htt-consult.com> writes:

> This is an item that goes back to the beginning of ESP work:
>
> Minimally, how does the higher level 'learn' that it is secure:
>
> E2E or TE2TE?
>
> Encrypted/Authenticated/CrCed...  ?
>
> And as ESP has a seq#, how might it be convied to the higher layer?
>
> Case in point:  MAVlink has a 1-byte seq# in its payload.  How might this be
> provided by ESP?
>
> https://mavlink.io/en/guide/message_signing.html
>
> So I have been thinking about this vis-a-vis diet-esp.  What is the
> mechanism/trigger that can best work across a number of higher layers to inform
> of operating environment and values available (seq#)?
>
> Is this done anywhere now?

If you're asking for a generic API mechanism in unix, for datagrams it would be recvmsg. Recvmsg uses a msghdr which can include control data (cmsghdr). That is the way that lower layer information associated with packets is passed up to the application.

man recvmsg
man cmsg

I don't know if any ESP data is currently passed with this method though.

Thanks,
Chris.



>
> Bob
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

v2.23.0 | Report a Bug | By Email