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

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]