IETF Logo Mail Archive

Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01]

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 29 November 2019 19:18 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 BE5C712013A for <ipsec@ietfa.amsl.com>; Fri, 29 Nov 2019 11:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 TgGL7h4IZhfJ for <ipsec@ietfa.amsl.com>; Fri, 29 Nov 2019 11:18:03 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418D2120105 for <ipsec@ietf.org>; Fri, 29 Nov 2019 11:18:03 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C218B3897B; Fri, 29 Nov 2019 14:14:31 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9C4BC66D; Fri, 29 Nov 2019 14:18:01 -0500 (EST)
To: Christian Hopps <chopps@chopps.org>, IPsecME WG <ipsec@ietf.org>
In-Reply-To: <C6E9B9B8-EE15-4E86-8C39-77BCFF50ADC2@chopps.org>
References: <039e01d5a5f2$ac51d350$04f579f0$@gmail.com> <A8BDEB5B-332E-4767-9EC6-9AF4CFA2E34B@chopps.org> <042301d5a6b6$bc8e9fe0$35abdfa0$@gmail.com> <C6E9B9B8-EE15-4E86-8C39-77BCFF50ADC2@chopps.org>
From: Michael Richardson <mcr+ietf@sandelman.ca>
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Fri, 29 Nov 2019 14:18:01 -0500
Message-ID: <875.1575055081@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Lz5SdbH-xBVbSafsPBB9z-SByNg>
Subject: Re: [IPsec] ESP next payload number [Re: Some thoughts regarging draft-hopps-ipsecme-iptfs-01]
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 29 Nov 2019 19:18:05 -0000

As I understand it, the question is:

  ESP(np=??)[IP-fragment, .., IP-fragment, padding]
  IPvX(np=ESP)
  L2

What will the ?? be.   I agree that it makes no sense to mark this as IPIP.
I see that we could re-use TF-ESP's number here if we got push-back.
 a) It would make no sense to put a TF-ESP inside an ESP in "transport" mode.
 b) nobody uses TF-ESP, we should just deprecate it :-)

But, before we do this, we should just ask for a number.
I don't see a reason to support transport inside of this formulation, I'd
have to go back the document to see why it might be difficult to do, but if
it's not hard to do, then don't forbid it.

(We also shouldn't forbid transporting Elephants in small clown cars, but I
don't recommend that either)

-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email