Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt

Tom Herbert <tom@herbertland.com> Tue, 05 March 2024 02:11 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2871DC180B72 for <int-area@ietfa.amsl.com>; Mon, 4 Mar 2024 18:11:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland.com
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 k70RxUvtB41V for <int-area@ietfa.amsl.com>; Mon, 4 Mar 2024 18:11:52 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C13C17C88A for <int-area@ietf.org>; Mon, 4 Mar 2024 18:11:51 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-563c595f968so7607643a12.0 for <int-area@ietf.org>; Mon, 04 Mar 2024 18:11:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1709604709; x=1710209509; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WlXxr+3t8pIyXtVPa6GwOugvzDbmzUfh1Qh8Fclrl78=; b=LxhPTRftJRuGPXZD9MZgce4ssRVE+F5HbK0Z2Kdc656CAeE0s2SW3vd4++FD8w5DMe 0ts3bhu4LLSlTEwFshjZUhHLUJByICvbvU+RxMHzQfrmMth2OxBpkwbL12q3iFSIXN/v mMzTGERqwhdRM/pZIo5TB4LQ0J0Qi1ZkC2ReRNrM9mj+bJhMdfaSLFdzuAs6gXWuv5Br A4pwhUrFUPiCOi15pLaWm1jhCgp0Jn9uKSE6sEK/FEAJEDGdIs2qTP64q+f8uTxZ2KJE XBcGEBpbCMswFuWAtPPNRq1UFt4aj3kXMSJdko5jMxiraIlVDXbU90rPPaSOVvI5rb8f eAbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709604709; x=1710209509; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WlXxr+3t8pIyXtVPa6GwOugvzDbmzUfh1Qh8Fclrl78=; b=JsZCiK0/TgD9SCHloHMuc1qs1T9mOYZK+tvKcw9bxnS3+jO087ktd0AtObn6TDWWXd 59PnPYkaLSzxlsIP+3yisKDVyreBoYle701KQdOLb4GMRSJeAo8QZlwqeTIfT0foxPk2 klfwzOZvrHkqFyXxlGaBRVECZBLO9uMC3dPh2mejnYc+7lMwX5cfX/fY3Se2unbCTG96 X1nUpISXxVGbtjOLo06xtNpP51DNFkbx2KaZyCz0rQilRr/Of3QezyTSrd8srW8e+9nK z9pK7YPaqjPM+7S88YRqO42I6gDRqkp6wPETYAUrA9+/PeAnWxJzck8ulTc33ebQg1ht zMkA==
X-Gm-Message-State: AOJu0Yzdg2UNz7el0xXHUmabk+auuKbGbK1rYGsH6Ajo7s4xlzIJi6TX azHQeeDiO+/gCmKjp7rBWJ5FNYAGdKL43IIrL9AKdaYsW6n/D35ChcrnsLts2E6XOIbVlelmgK0 Ut/tgPgGeV4SzsnOMWv7j9NpDx1DEhkQtc78a9UR1utXgse8=
X-Google-Smtp-Source: AGHT+IF21BvxaSNSb9tPxqKSpPRwAIq+SHPgyjPo4upLxly7bqUySheI4sTJl7EMkssyOBm2odEgEYMgCnBX9t70ys4=
X-Received: by 2002:a50:c8c9:0:b0:567:737f:e90e with SMTP id k9-20020a50c8c9000000b00567737fe90emr1262040edh.30.1709604709239; Mon, 04 Mar 2024 18:11:49 -0800 (PST)
MIME-Version: 1.0
References: <170865175505.14082.3856617737779580933@ietfa.amsl.com> <CALx6S363oh+7rNMaMa0s+9A-xeyLBy+ct-Q_Bx0xQm_di1PPJA@mail.gmail.com> <ZeZjGyxmuapXz5tb@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <ZeZjGyxmuapXz5tb@faui48e.informatik.uni-erlangen.de>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 04 Mar 2024 18:11:38 -0800
Message-ID: <CALx6S34OFL7tzabL+RMvB3nkad5k9esCD_dFpMi6DUtUEG-Dmg@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: int-area <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/M10gRBogBHTcg1fnUehp0Q8hu-Q>
Subject: Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2024 02:11:56 -0000

Hi Toerless, thanks for the questions!

On Mon, Mar 4, 2024 at 4:11 PM Toerless Eckert <tte@cs.fau.de> wrote:
>
> Just some questions about AH/ESP here:
>
> What actually is (so far, without your draft) the technical benefits
> and/or differences of ESP and AH in IPv6 being classified as IPv6
> extension headers, as opposed in IPv4, where they are currently
> defined as "yet another (next level) Protocol ?

We can treat them as EH for purposes of extension header ordering in
section 2.2. Also, IPv4 AH needs to be updated to take EH into account
as mentioned below. Other than that I don't believe there are any
substantive differences.

>
> Any difference in APIs for example ? I guess i might be able to implement
> ESP/AH in IPv6 in user-level because i can expose extension header
> to user-level UDP sockets (not 100% sure), whereas in IPv4 i would need
> a (raw) IP socket to get them up to userland ??

No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel
changes to Linux will be straightforward.

>
> Any other functional differences ? Aka: i couldn't find a simple:
>
> "If i want to define a new protocol header, should i call it an
>  extension header or an ipv6 extension header - for Dummies" ?
>

I think there are IPv6 extension headers and IPv4 extension headers.
IPv4 extension headers are probably just a subset of IPv6 extension
headers.

> (at least for those examined only on the receiver obviously. HBH i do get.
>
> I think you did not write it explicitly, but i would assume the IANA
> Assigned Internet Protocols Numbers column "IPv6 Extension Header" would

Yes, we should request an IPv4 EH attribute in this table (or maybe a footnote)

> be renamed to "IP/IPv6 Extension Header". But when this was done
> to AH/ESP, and there actually is a functional difference expressed by
> this extension header (as opposed to non-extension header) status, then
> what be the imapct of this ? Aka: I upgrade my linux kernel to extension
> header and all my AH/ESP breaks ?  Or i do get the benefit of above
> (userland access) ?
>
> Would there be any (backward compatibility) reason to have new codepoints in IPv4 for ESP/AH
> with this extension header status and leave the existing (non extension
> header) codepoints alone ?

No, I don't think we need that. ESP/AH should be backwards compatible.
For instance, if someone sends AH with HBH in IPv4 then they know that
their using EH and AH would take into account mutable HBH options. If
the packet is sent to a host that supports IPv4 EH then they would
know how to process the AH with HBH correctly. If the packet is sent
to a legacy node that doesn't support EH, then the packet will bv
dropped since the host doesn't recognize protocol 0 (HBH). There is no
behavioral change at either the receiver or the sender if someone
sends an AH with no other EH. The draft will need to update RFC4302 to
describe AH processing with IPv4 EH present.

RFC4303 needs an update as well, but that's just to say that EH after
the ESP is covered by the encryption, but I don't believe that
materially changes the requirements.

Tom

>
> Cheers
>     Toerless
>
> On Thu, Feb 22, 2024 at 05:40:31PM -0800, Tom Herbert wrote:
> > Hi,
> >
> > I updated the IPv4 extension headers draft. I structured it to be
> > self-contained without any normative references for IPv6 RFCs. It's a
> > little bigger, but about 80% of the text is cut-and-paste from other
> > RFCs and drafts.
> >
> > Comments are appreciated!
> >
> > Tom
> >
> > ---------- Forwarded message ---------
> > From: <internet-drafts@ietf.org>
> > Date: Thu, Feb 22, 2024 at 5:29 PM
> > Subject: New Version Notification for draft-herbert-ipv4-eh-03.txt
> > To: Tom Herbert <tom@herbertland.com>
> >
> >
> > A new version of Internet-Draft draft-herbert-ipv4-eh-03.txt has been
> > successfully submitted by Tom Herbert and posted to the
> > IETF repository.
> >
> > Name:     draft-herbert-ipv4-eh
> > Revision: 03
> > Title:    IPv4 Extension Headers and Flow Label
> > Date:     2024-02-23
> > Group:    Individual Submission
> > Pages:    47
> > URL:      https://www.ietf.org/archive/id/draft-herbert-ipv4-eh-03.txt
> > Status:   https://datatracker.ietf.org/doc/draft-herbert-ipv4-eh/
> > HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-eh
> > Diff:     https://author-tools.ietf.org/iddiff?url2=draft-herbert-ipv4-eh-03
> >
> > Abstract:
> >
> >    This specification defines extension headers for IPv4 and an IPv4
> >    flow label.  The goal is to provide a uniform and feasible method of
> >    extensibility that is common between IPv4 and IPv6.
> >
> >
> >
> > The IETF Secretariat
> >
>
> --
> ---
> tte@cs.fau.de