Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

Christian Hopps <chopps@chopps.org> Thu, 15 October 2020 20:29 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 044463A084D for <ipsec@ietfa.amsl.com>; Thu, 15 Oct 2020 13:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 3OBUy2WGni6U for <ipsec@ietfa.amsl.com>; Thu, 15 Oct 2020 13:29:06 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 589EF3A0879 for <ipsec@ietf.org>; Thu, 15 Oct 2020 13:29:04 -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 A579E61676; Thu, 15 Oct 2020 20:29:03 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <F8E266C0-CACB-4B4C-83F3-C5E05F2B547C@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_E4734495-9295-423F-9B97-9651610913DB"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 15 Oct 2020 16:29:02 -0400
In-Reply-To: <24456.43991.701332.956314@fireball.acr.fi>
Cc: Christian Hopps <chopps@chopps.org>, Valery Smyslov <smyslov.ietf@gmail.com>, Lou Berger <lberger@labn.net>, ipsec@ietf.org
To: Tero Kivinen <kivinen@iki.fi>
References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <ab981da9-9735-b6a9-851d-736330748ce6@labn.net> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net> <24454.5506.450515.501200@fireball.acr.fi> <001701d6a1f7$76981240$63c836c0$@gmail.com> <24454.51962.50262.36523@fireball.acr.fi> <DFDCAC27-5099-4D5A-AEDA-C81A8C167002@chopps.org> <24456.43991.701332.956314@fireball.acr.fi>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/pCwY0dlyVLkbZOUM0KmK2lDvHq0>
Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]
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: Thu, 15 Oct 2020 20:29:15 -0000

Hi Tero,

We are defining the payload in this document, the payload is meant for ESP. ESP has a payload identifier why can't we use it? It feels like the clean KISS solution to me. Yes, we are doing IKE negotiation, but using the designed for payload identifier also allows the payload to be identified in non-IKE scenarios (packet captures, error logging, etc..), therefor it's not just KISS it's also more *robust* and thus I believe a better design.

I think your main objection is over actually making an IP protocol number allocation. If that's what it is then let's focus on that point. It may be easier to make progress that way.

For example we could switch to our backup solution and re-use an existing IP protocol number which would never be carried in ESP (e.g., IPv5). I feel it's a bit less elegant, but still workable, and leaves us with the KISS/more robust outcome.

Thanks,
Chris.

> On Oct 15, 2020, at 4:06 PM, Tero Kivinen <kivinen@iki.fi> wrote:
> 
> Christian Hopps writes:
>> I really don't understand the extreme back pressure against using
>> ESP the way it was designed. The next-header field is supposed to
>> identify the payload, it does so for every other payload ESP
>> carries. Any other solution to somehow infer the payload type some
>> other way *has* to be seen as a hack. Why do we need a hack?
> 
> Because the next-header field identifies the protocol DEFINED
> ELSEWHERE that ESP moves around.
> 
> If we want to make modifications to the TCP protocol, and want to
> allocate new Protocol Number for it, we do not that in IPsecME WG even
> when that new version of TCP could be transmitted over IPsec also.
> 
> When ESPv3 (RFC4303) added new features like support for combined mode
> algorithms we did not allocate new protocol number for that. We
> decided that we use IKE to identify whether Child SA negotiates
> anything that requires ESPv3, and if so then ESPv3 packet format is
> used, otherwise ESPv2 (RFC2406) is used.
> 
> So the basic idea is that IPsec and ESP is transporting protocols
> defined elsewhere. That does not mean that content of the ESP protocol
> can't change, we "own" the ESP format, so we can change it in any ways
> we seem needed, and we can negotiate things using IKE to specify the
> format specific Child SA is using.
> 
> Now if you are trying to define completely new protocol for generic IP
> use, and because it can also be used in the IPsec, you want to
> standarize that in the IPsecME WG, I do not think that belongs to the
> IPsecME charter. If this protocol is really going to be general use
> encapsulation protocol then it needs to be specified somewhere else
> (most likely in different Area than security).
> 
> If this is not general use, but just optimization where we can put
> multiple IP packets inside one ESP packet to provide traffic flow
> security, then we can negotiate that in IKE, and we do not need extra
> protocol number for it, and we can do it here.
> 
> I am still unclear which one of those protocols you are trying to
> define?
> 
>> The fact that using a payload identifier the way ESP intended also
>> allows us to do things like handle receipt of said payload without
>> extra configuration, or use the payload outside of ESP are just
>> benefits from good design, they aren't indicative of doing something
>> incorrectly, the opposite in fact. They also shouldn't even be
>> needed to justify using ESP the way it was designed to be used.
> 
> So then this belongs to different area, as it does not have any real
> connection to IPsec, it just one of the protocols we can encapsulate
> in ESP.
> 
> Also now when I actually checked you draft, I noticed that it has some
> congestion control things in it too, and that is something that do
> require very careful checking by other areas.
> 
>> This is all very strange to me, this want to not use the next-header
>> field to, you know, identify the next header.
> 
> As I said that is fine by me if it is protocol defined outside the
> IPsecME. I just do not think it belongs to the IPsecME to define new
> internet protocol encapsulating multiple IP packets in, and
> fragmenting them, and doing congestion control on them.
> 
> Our main charter says:
> 
> 	Its purpose is to maintain the IPsec standard and to
> 	facilitate discussion of clarifications, improvements, and
> 	extensions to IPsec, mostly to ESP and IKEv2.
> 
> meaning we work for ESP and IKEv2, not for making new generic IP
> protocols. Also the TFC section of charter says:
> 
> 	The demand for Traffic Flow Confidentiality has been
> 	increasing in the user community, but the current method
> 	defined in RFC4303 (adding null padding to each ESP payload)
> 	is very inefficient in its use of network resources. The
> 	working group will develop an alternative TFC solution that
> 	uses network resources more efficiently.
> 
> Which I did understood that we still work by modifying the ESP
> protocol and that we do not define new generic protocols for
> encapsulating IP packets and transport that inside ESP (which would
> not need any changes to the ESP or IKE, as we already have a way of
> negotiating the traffic selectors for any IP protocol we want to
> tranport inside ESP).
> 
> Of course there would be some security implications for such protocol
> as you would need to specify exit tunnel checks for those packets
> coming out from the new protocol, which is why I think it is better
> done by modifying ESP.
> --
> kivinen@iki.fi
>