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

From: Christian Hopps <[email-masked]>
Date: Mon, 12 Oct 2020 11:58:38 -0400

Hi ipsecme and chairs,

This is a small update to the IPTFS draft which incorporates the last 2 changes that had been requested over the last year or so.

1. As requested last year, it dispenses with the late-enabled functionality, replacing it with a SHOULD clause supporting receiving IPTFS encapsulated ESP payloads w/o extra configuration.

2. It highlights that one must send payloads that carry inner packet fragments using consecutive ESP sequence numbered packets (with a caveat for all pad payload insertion).

We feel the document is quite stable at this point and would thus like to ask for moving to WG Last Call.

Thanks,
Chris.

> On Sep 30, 2020, at 12:25 PM, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF.
> 
>        Title           : IP Traffic Flow Security
>        Author          : Christian Hopps
> 	Filename        : draft-ietf-ipsecme-iptfs-02.txt
> 	Pages           : 26
> 	Date            : 2020-09-30
> 
> Abstract:
>   This document describes a mechanism to enhance IPsec traffic flow
>   security by adding traffic flow confidentiality to encrypted IP
>   encapsulated traffic.  Traffic flow confidentiality is provided by
>   obscuring the size and frequency of IP traffic using a fixed-sized,
>   constant-send-rate IPsec tunnel.  The solution allows for congestion
>   control as well.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 13 Oct 2020 10:22:58 +0300

Hi Chris,

> 1. As requested last year, it dispenses with the late-enabled functionality, replacing it with a SHOULD clause
> supporting receiving IPTFS encapsulated ESP payloads w/o extra configuration.

I prefer this functionality to be removed. Either you are doing classical tunnel/transport in the SA or you are doing IPTFS.
>From my understanding it's just another encapsulation mode. Otherwise we have the following problems:
- Since this functionality is optional its capability must be negotiated (or indicated by the peers) in IKEv2. 
   And negotiation of IPTFS features is already complex enough.
- It complicates processing in the kernel. E.g, it's not clear for me what "on receipt of the first IP-TFS payload" means.
   If packets are reordered in the network and the first received IPTFS packet is not the first sent IPTFS packet?
   What to do with the non-IPTFS packets sent before first IPTFS packet but received after it? And so on.
   IPTFS processing in the kernel is already quite complex, let's not introduce additional complexity.
- I see no value in this functionality apart from the debugging and I don't want debugging capability to 
   be present in the RFC, so that people, who really don't need it, implement it in
   their products introducing new bugs. You may argue, that you made it optional, but SHOULD is very close 
   to MUST and in addition making it optional only complicates negotiation of IPTFS.

So, please, remove it.

> 2. It highlights that one must send payloads that carry inner packet fragments using consecutive ESP
> sequence numbered packets (with a caveat for all pad payload insertion).

That's useful clarification, thanks.

Regards,
Valery.

---

From: Lou Berger <[email-masked]>
Date: Tue, 13 Oct 2020 07:27:16 -0400

Valery,

Please see below.

> I prefer this functionality to be removed. Either you are doing classical tunnel/transport in the SA or you are doing IPTFS.

I agree that there is added code complexity, but have you considered the 
operational benefit of having this?  Specifically (a) adding yet another 
required configuration parameter that must match at both ends to get an 
ipsec tunnels up and (b) what it takes to go from an operational non-TFS 
configuration to a TFS configuration in one or both directions?

>     And negotiation of IPTFS features is already complex enough.

I'm not sure what needs to be negotiated here -- without negotiation the 
behavior is the same as would be seen with a miss-configured  endpoint 
or mismatch in TFS config that will occur without the option.

>     What to do with the non-IPTFS packets sent before first IPTFS packet but received after it? And so on.

This is an implementation choice, right?  Why not just drop it or 
process it as the implementation sees fit?

>     to MUST and in addition making it optional only complicates negotiation of IPTFS.

My view is that the main benefit is simpler configuration and removing a 
requirement for timing manual configuration changes at each end of a 
tunnel.  Configuring IPsec is complex enough,  from the operational 
perspective, I'd prefer to see this as a MUST, but can live with 
SHOULD.  (IMO - Getting the code right once per implementation is 
greatly outweighed by the returns in not having to impose more 
configuration and configuration timing burdens.)

Thanks,

Lou

---

From: Christian Hopps <[email-masked]>
Date: Tue, 13 Oct 2020 08:06:26 -0400

> On Oct 13, 2020, at 7:27 AM, Lou Berger <[email-masked]> wrote:
> 
> Valery,
> 
> Please see below.
> 
> I agree that there is added code complexity, but have you considered the operational benefit of having this?  Specifically (a) adding yet another required configuration parameter that must match at both ends to get an ipsec tunnels up and (b) what it takes to go from an operational non-TFS configuration to a TFS configuration in one or both directions?

FWIW, there really was no complexity to support this. If one chooses to support it (it is a SHOULD not a MUST after all), you initialize a small amount of receive side IPTFS state for INBOUND SAs. The change to add this functionality to our implementation required:

  Code: add global always rx tfs ability

  3 files changed, 38 insertions(+), 6 deletions(-)
  ...

Less than 50 lines of (init/config) code were modified, quite minimal actually. Perhaps most importantly to your concern, nothing in the data-path (fast-path) actually needs to change.

It simplifies configurations for people that are using systems other than IKE for IPsec configuration, it's easy to add to the code, and it's not required (SHOULD not MUST). So I think it's good support this.

Thanks,
Chris.

> I'm not sure what needs to be negotiated here -- without negotiation the behavior is the same as would be seen with a miss-configured  endpoint or mismatch in TFS config that will occur without the option.
> 
> This is an implementation choice, right?  Why not just drop it or process it as the implementation sees fit?
> 
> My view is that the main benefit is simpler configuration and removing a requirement for timing manual configuration changes at each end of a tunnel.  Configuring IPsec is complex enough,  from the operational perspective, I'd prefer to see this as a MUST, but can live with SHOULD.  (IMO - Getting the code right once per implementation is greatly outweighed by the returns in not having to impose more configuration and configuration timing burdens.)
> 
> Thanks,
> 
> Lou
> 
>> So, please, remove it.
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 13 Oct 2020 16:16:39 +0300

Hi Lou,

> >> This is a small update to the IPTFS draft which incorporates the last 2 changes that had been requested
> over
> >> the last year or so.
> >>

I can't buy these arguments. Using IPTFS is negotiated in IKEv2 via 
exchange of USE_IPTFS notify (BTW, note a typo in Section 5.1 title: USE_TFS instead of USE_IPTFS).
So, unless you upgrade both ends and update configuration IPTFS won't be used at all.
Once you upgrade one end you can add a configuration parameter to it to 
propose using IPTFS while being initiator. Until the other end is upgraded too,
it will ignore the USE_IPTFS notify and SA will be established in tunnel mode.
Once the other end is upgraded and its configuration is changed they 
will start using IPTFS.

> or mismatch in TFS config that will occur without the option.

Not true. If peers are misconfigured, then IPTFS won't be negotiated and SA will be established in tunnel mode
(if using IPTFS is optional for both) or not established at all (if using PFS is mandatory for the peer suggesting it).
On the contrary, if switching from tunnel to IPTFS on live SA is not negotiated, and one of the peers doesn't
support it, then when the other peer switches from tunnel mode to IPTFS on live IPsec SA and starts sending
IPTFS packets, then the first peer will most probably drop them. We'll get a classical "black hole", and the worst
thing that it won't be detected by liveness checks, since IKE SA will be perfectly workable.

> process it as the implementation sees fit?

Right, but it complicates processing. Currently I uniformly process all the packets within window.
Now I have to remember on which E(SN) the switching occured and process previous
packets as tunnel (or start dropping them) and subsequent packets as IPTFS.

> configuration and configuration timing burdens.)

Please, see above. Since using IPTFS is negotiated, I see no simplification
in configuring. You still need to upgrade and configure properly both ends
before you can use it.

If you badly need this feature, then please make it MAY and negotiable,
so that people can ignore it. SHOULD is too strong for it,
leaving it non-negotiable is just unacceptable, IMHO.

Regards,
Valery.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 13 Oct 2020 09:22:52 -0400

> On Oct 13, 2020, at 9:16 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Lou,
> 
>> Valery,
>> 
>> Please see below.
>> 

IPTFS is not always negotiated, as IKE is not always used. Supporting zero-conf IPTFS receive is very useful for supporting these non-IKE use-cases.

Thanks,
Chris.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 13 Oct 2020 16:43:10 +0300

Hi Chris,

IPTFS is not always negotiated, as IKE is not always used. Supporting zero-conf IPTFS receive is very useful for supporting these
non-IKE use-cases.

          If you plan to use IPTFS without IKE, then make it clear in the draft that 

          Zero-Conf is only applicable for these use cases and MUST NOT be used

          if IKE is employed. That will make me happy :-)

          Regards,

          Valery.

Thanks,

Chris.

Regards,
Valery.

Thanks,

Lou

So, please, remove it.

Regards,
Valery.

Thanks,
Chris.

Abstract:

---

From: Lou Berger <[email-masked]>
Date: Tue, 13 Oct 2020 09:59:44 -0400

I can live with MAY.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 13 Oct 2020 17:06:39 +0300

> I can live with MAY.

OK, but it must be negotiable in any case if you plan to use it with IKE.
Otherwise we'll get black holes.

---

From: Lou Berger <[email-masked]>
Date: Tue, 13 Oct 2020 10:25:44 -0400

Valery,

How about this:

OLD
    Receive-side operation of IP-TFS does not require any per-SA
    configuration on the receiver; as such, an IP-TFS implementation
    SHOULD support the option of switching to IP-TFS receive-side
    operation on receipt of the first IP-TFS payload.

NEW
    Receive-side operation of IP-TFS does not require any per-SA
    configuration on the receiver; as such, for tunnels created
    without IKE, an IP-TFS implementation
    SHOULD support the option of switching to IP-TFS receive-side
    operation on receipt of the first IP-TFS payload for tunnels.

I can live with MAY, but would prefer SHOULD.

Does this work for you?
Lou

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 13 Oct 2020 17:37:50 +0300

Valery,

How about this:

OLD

NEW

 
Does this work for you?
 
              Yes, with the following addition.
 
   If IKE is used to negotiate using IP-TFS, then such switching
   MUST NOT take place.

              With this addition I don’t mind having SHOULD for ike-less case.
 
              Regards,
              Valery.
              
Lou

I can live with MAY.

---

From: Lou Berger <[email-masked]>
Date: Tue, 13 Oct 2020 12:05:35 -0400

Valery,

 >    If IKE is used to negotiate using IP-TFS, then such switching MUST 
NOT take place.

I read this added line as saying you can switch from tunnel to TFS, I 
think you mean that use of TFS is controlled via IKE.  How about?

    If IKE is used to negotiate using IP-TFS, then use of TFS is 
controlled per Section 5.1.

Lou

On 10/13/2020 10:37 AM, Valery Smyslov wrote:
> configuration on the receiver; as such, for tunnels created    without 
> IKE, an IP-TFS implementation    SHOULD support the option of 
> switching to IP-TFS receive-side    operation on receipt of the first 
> IP-TFS payload for tunnels.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 13 Oct 2020 20:32:32 +0300

> I can live with MAY, but would prefer SHOULD.

I have to admit that I have not read this draft, but noting, that most
of the cipher we use do require automated key management like IKE, I
just wonder are you really going to be limited to 3DES, or what
automated key management you are going to be using instead of IKE, and
how can you guarantee that it actually does its job correctly for
securing the key management over reboots etc.
-- 
[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 13 Oct 2020 16:40:00 -0400

Hi Tero,

see below
> securing the key management over reboots etc.

I'm not advocating ike vs ike-less, just trying to have a comprehensive 
solution.  One example ikeless usecase is captured by the YANG model in 
last call: 
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09

Lou

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Oct 2020 00:00:50 +0300

> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09

Which will require similar behavior from the IPsec part than IKE,
meaning you can't really change any parameters on the fly for existing
SAs. You can't change for example the ciphers of the existing SA, and
expect that to work.

My understanding for that is that ike-less will not change any
parameters of the existing SAs in the SAD, as that would definitely
break everything, but instead they will allocate new SPI, install new
SAD entry, and then remove the old SAD entry which causes the traffic
move to use the newly created SAD entry.

So for that use, there is no point of having a way to turn on IPTFS in
the middle of SA use time, exactly as there is no need to try to
change algorithms of the existing SAs. If you do that kind of things,
you just create new SA, and delete old one. I am not sure whether this
should be reflected on the draft-ietf-i2nsf-sdn-ipsec-flow-protection
somehow, i.e., indicating that most (if not all) of the items in the
sad-entry are write once type of things, i.e., you can write them
once, but you can't modify them once they have been set, and only way
to change them is to delete the whole sad-entry and recreate it with
new values (most likely doing it other way round, i.e., first create
new and delete old). 
-- 
[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 13 Oct 2020 18:31:03 -0400

Tero,

     are you saying you not happy with the proposed text as discussed 
with valery?

Thanks,

Lou

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 14 Oct 2020 09:26:43 +0300

Hi Lou,

Valery, 

>    If IKE is used to negotiate using IP-TFS, then such switching MUST NOT take place.

I read this added line as saying you can switch from tunnel to TFS, I think you mean that use of TFS is controlled via IKE.  How about?

   If IKE is used to negotiate using IP-TFS, then use of
   TFS is controlled per Section 5.1.
 
              I think the text is still a bit ambiguous,  since previous sentence uses a normative SHOULD
              to support switching from tunnel to IPTFS and the proposed text doesn’t forbid this
              behavior explicitly if IKE is used. I’d like to see more explicit language for IKE case.
              How about:
 
   If IKE is used to negotiate using IP-TFS, then use of
   TFS is controlled per Section 5.1, and thus the option of switching
   to IP-TFS receive-side operation on receipt of the first IP-TFS payload
   MUST NOT be used.
 
              Feel free to change the text keeping its sense...
 
              Regards,
              Valery.

Lou

Valery,

How about this:

OLD

NEW

 
Does this work for you?

 
 
              Regards,
              Valery.

             
Lou

I can live with MAY.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 14 Oct 2020 09:58:46 +0300

Hi Tero,

> SAs. You can't change for example the ciphers of the existing SA, and

In fact, unlike changing e.g. cipher on the fly, that is not possible,
because the cipher used is not present in the ESP packet, so that you 
cannot distinguish two ESP packets with different ciphers, you can distinguish 
tunnel packets from IPTFS packets on receiving side 
(by analyzing Next Header), so technically the proposed
switching is workable. That said, I fully agree with you
that it is a very bad idea and must be prohibited,
at least for traditional IPsec. 

I care less about other use cases (I recall that authors wanted
to use IPTFS not only for IPsec, but as more generic 
mechanism to pack several IP packets into one). So, I may leave
with this option if it will be explicitly prohibited
for traditional IPsec. IKE-less (l2nsf) use case is a corner case,
I tend to agree with you that it should be prohibited
for this case too.

Regards,
Valery.

---

From: Christian Hopps <[email-masked]>
Date: Wed, 14 Oct 2020 03:40:48 -0400

Indeed, this isn't about switching a pair of SAs to IPTFS in the middle of the tunnel operation. This is only about supporting the receipt of IPTFS as a payload in ESP.

Zero conf (or globally config enabled) receive support of IPTFS payloads is seen by some as a real value add. I'm not sure what the kerfuffle is all about. :)

Thanks,
Chris.

> On Oct 14, 2020, at 2:58 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Tero,
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 14 Oct 2020 11:01:09 +0300

HI Chris,

> Indeed, this isn't about switching a pair of SAs to IPTFS in the middle of the tunnel operation. This is only
> about supporting the receipt of IPTFS as a payload in ESP.

I admit, that English is not my native language :-), but the text in the draft in my reading 
suggests exactly what you write it is not suggesting - switching to IP-TFS in the middle of tunnel operation
("on receipt of the first IP-TFS payload"):

2.4.  Zero-Conf Receive-Side Operation On The SA.

If you intention was to require that all implementations SHOULD just support receiving IP-TFS packets
(say, should implement IP-TFS), then the requirement is strange for me - 
in fact you require that all implementations support this extension.

So, if you really meant some other thing, then the current text 
must be completely rewritten, so that it is clear for non-native readers (like me).

Regards,
Valery.

> Zero conf (or globally config enabled) receive support of IPTFS payloads is seen by some as a real value add.
> I'm not sure what the kerfuffle is all about. :)
> 
> Thanks,
> Chris.
>

---

From: Christian Hopps <[email-masked]>
Date: Wed, 14 Oct 2020 04:07:47 -0400

What is intended is that an implementation can process inbound IPTFS payloads w/o actually explicitly configuring the inbound SA to be in "IPTFS-mode" (zero-conf). That is all.

Thanks,
Chris.

> On Oct 14, 2020, at 4:01 AM, Valery Smyslov <[email-masked]> wrote:
> 
> HI Chris,
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Oct 2020 12:55:06 +0300

Valery Smyslov writes:
> In fact, unlike changing e.g. cipher on the fly, that is not
> possible, because the cipher used is not present in the ESP packet,
> so that you cannot distinguish two ESP packets with different
> ciphers, you can distinguish tunnel packets from IPTFS packets on
> receiving side (by analyzing Next Header), so technically the
> proposed switching is workable. That said, I fully agree with you
> that it is a very bad idea and must be prohibited, at least for
> traditional IPsec.

I have never understood why the IPTFS packets needs to be identified
by the Next Header. We do not include cipher algorithm in the ESP
packet, so that is known by the SA information. We could do exactly
same for the IPTFS, i.e., if all packets inside the specific SA is
always IPTFS packets, then there is no need to identify whether IPTFS
is used or not in the Next Header field, and there would be no need to
allocate new IP protocol number for this.

If the reason we need new IP protocol number is just because they want
to be able to this switching of the IPTFS on in the middle of the
IPsec SA when NOT using IKE, then I think that is not very good reason
for allocating new IP protocol number. 

> mechanism to pack several IP packets into one).

I would like to understand what these other use cases are and how they
affect the use case for IPsec. I mean if those use cases are just "we
want to make generic mechanism" without any specific use cases, there
is no need to think about the Early allocation of the IP protocol
number.

> So, I may leave with this option if it will be explicitly prohibited
> for traditional IPsec.

And if interoperability testing etc of the IPTFS in the IPsec use case
is done using IKE, and in that case we do not need new IP protocol
number, as we can know from the IPsec SA whether IPTFS is enabled or
not. There is no need to know that per packet basis. And In that case
IP protocol number allocation can be later, when other uses cases
emerge.

> IKE-less (l2nsf) use case is a corner case, I tend to agree with you
> that it should be prohibited for this case too.

Definitely. Actually I think the i2nfs document should probably say
something about changing SAD stucture during on the fly. I would
expect that most of the implementations in kernel do not really allow
easy way of modifying the replay window or things like that while the
SA is being used. In normal case there is no need to ever set the for
example replay window, it will start from all zeros when SA is
created, and automatically updated after that. Other things like
sequence numbers or IV can cause serious security issues if they are
modified wihtout following specific rules.

With my quick check of the i2nfs draft I did not see whether it has
any text saying those things are create once, and after that read only
or not. I think it should have that kind of text somewhere....
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Oct 2020 13:19:08 +0300

Christian Hopps writes:
> What is intended is that an implementation can process inbound IPTFS
> payloads w/o actually explicitly configuring the inbound SA to be in
> "IPTFS-mode" (zero-conf). That is all. 

And if IKE is used what is the use case for that?

IKE allows easy way of agreeing on the set of parameters for each
IPsec SA, and agreeing on the mode of the encapsulation is one thing
it already does. It does negotiate whether the IPsec SA is in tunnel
or transport mode, and for my view the IPTFS is just one more mode for
that, i.e., something that can be negotiated when IPsec SA is created
using IKE, and then that encapsulation mode is used. There is no need
to know or do that per packet basis.

In theory in recipient we could detect tunnel mode by looking at the
next header field of the inner packet, and if we see it is IP inside
the packet, then we would assume it is tunnel mode, and enable tunnel
mode processing. We do not do that, we do negotiate whether the IPsec
SA is tunnel or transport mode and create IPsec SA either in tunnel or
in transport mode.

Earlier there was also another encapsuluation mode called a Bound
End-to-End Tunnel (BEET) mode for ESP [1] that was also proposed, and
in that case it would have been impossible to detect the mode from the
incoming packet, as lots of the information needed to reconstruct the
end to end IP header is stored in the SA.

Anyways we do store things in the IPsec SA when we create them, we do
have negotiation mechanism to agree on those parameters and we can use
them, we do not need to process things per packet basis. 

[1] https://tools.ietf.org/html/draft-nikander-esp-beet-mode-09
-- 
[email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Wed, 14 Oct 2020 06:20:37 -0400

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?

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.

This is all very strange to me, this want to not use the next-header field to, you know, identify the next header.

Thanks,
Chris.

> On Oct 14, 2020, at 5:55 AM, Tero Kivinen <[email-masked]> wrote:
> 
> Valery Smyslov writes:
>> Hi Tero,
>> 
> [email-masked] <mailto:[email-masked]>

---

From: Christian Hopps <[email-masked]>
Date: Wed, 14 Oct 2020 06:24:27 -0400

> On Oct 14, 2020, at 6:19 AM, Tero Kivinen <[email-masked]> wrote:
> 
> Christian Hopps writes:

The text Lou and Valery ended up with indicated this was not used in the IKE case.

> them, we do not need to process things per packet basis.

Are you saying that the next-header field is useless then? I mean the code I've worked on parses the next header field on a per packet basis to handle the inner packet payload. I'm not interested in trying to redesign ESP with IPTFS, just use it as provided.

Thanks,
Chris.

---

From: Lou Berger <[email-masked]>
Date: Wed, 14 Oct 2020 10:49:10 -0400

Thanks Valery.  Based on the subsequent discussions, I suspect it may be 
best to just drop the whole section/capability.  So much for postel's law...

Lou

On 10/14/2020 2:26 AM, Valery Smyslov wrote:
>               I think the text is still a bit ambiguous,  since 
> previous sentence uses a normative SHOULD

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Oct 2020 14:59:11 -0400

Christian Hopps <[email-masked]> wrote:
    > 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?

I don't understand either.

Can we just let these guys get on with their work?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Oct 2020 16:06:03 -0400 (EDT)

On Wed, 14 Oct 2020, Christian Hopps wrote:

> 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?
> 
> 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.
> 

I see it as a useful feature that I can "enable" IPTFS on my existing
IPsec connection dynamically. Perhaps to avoid always sending traffic
when I have none, and mostly wanting my decoy traffic when I am doing
things (like typing over ssh, sending an email, etc)

I don't see how this would happen "automatically". It would be a user
invoked event.

Based on that, userland has to somehow trigger to kernel to switch from
regular ESP to IPTFS. We would need to define that (eg via Netlink or
PF_KEY).

But why not use a NOTIFY with a REKEY event to USE_IPTFS ? No need for
new PF_KEY/netlink messages, no new userland <-> kernel signaling. Just
use existing implemented IKE/IPsec protocols.

So I think I agree with Valery (and Tero). It is not really about what
the ESP packet format can or cannot do, but using existing channels for
on-the-fly reconfiguration. It would work the same as if you wanted to
switch a transport mode to tunnel mode or IPCOMP, rekey with(out)
USE_TRANSPORT or USE_IPCOMP.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 15 Oct 2020 23:06:47 +0300

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.
-- 
[email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Thu, 15 Oct 2020 16:12:37 -0400

Hi Paul,

My comment was only about using the next header field in ESP to identify the ESP payload. I believe we've already agreed to remove the zero-conf section as too controversial.

Tero, is suggesting that we should not use the next header field at all. That is what I don't understand.

Thanks,
Chris.

> On Oct 15, 2020, at 4:06 PM, Paul Wouters <[email-masked]> wrote:
>

---

From: Christian Hopps <[email-masked]>
Date: Thu, 15 Oct 2020 16:29:02 -0400

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 <[email-masked]> wrote:
> 
> Christian Hopps writes:

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 15 Oct 2020 23:31:07 +0300

Christian Hopps writes:
> Are you saying that the next-header field is useless then?

Nope. It is needed for transport mode, and also for tunnel mode, where
there are few possible values for it (4, 41, 59). 

> I mean the code I've worked on parses the next header field on a per
> packet basis to handle the inner packet payload.

In tunnel mode they most likely drop everything else than IP in IP,
right? Or do they really start processing TCP packets inside tunnel
mode SA?

> I'm not interested in trying to redesign ESP with IPTFS, just use it
> as provided.

So if you want to define new version of ip in ip that allows
encapsulating multiple ip packets inside one packet, then that should
not be done in the IPsecME WG.

IPv4 tunneling (protocol 4) was there long before IPsec, the IPv6
tunneling (protocol 41) was done by ipng wg etc. Neither one of those
are done in the IPsec WG, but ESP are using them as they are useful
things to do.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 15 Oct 2020 23:48:31 +0300

Christian Hopps writes:
> 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?

If that is only possible value the next-header field can have as all
packets of the Child SA which has been negotiated with USE_IPTFS then
what is the point of allocating number that is not needed. You can
simply say that next payload field will be transmitted as 0, and
ignored on the recipient as you already know the format packet inside
ESP because it was negotiated in the IKE. 

> 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.

So you want to allocate completely new protocol number from the 8-bit
registry, just so that you can print it out in the error logs and
auditing, instead of putting (use_ipftf ? "iptfs" : protocol number)?

Packet captures does not really help as ESP content is encrypted, and
most implementations do not really allow easy way of printing out the
traffic keys for wireshark etc use, and anyways wireshark has this
decode as XXX option where you can force it to decode it with whatever
protocol you think is inside, regardless whether there is protocol
number matching.

> I think your main objection is over actually making an IP protocol
> number allocation.

Actually doing early allocation.

> If that's what it is then let's focus on that point. It may be
> easier to make progress that way.

I need to justify why the WG thinks we need this done now, and why
this is going to be useful, and why this can't be done in other ways.

If I myself think it would be easier to do this by just negotiating it
in IKE, I have hard time convincing others.

> 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.

I do not think there is IP protocol number for IPv5, but if you really
want to have protocol number, why not use 253 that is reserved for
experimientation and testing.

This allows you to do your testing now, and you can write your draft
saying that as all payloads inside the ESP will be iptfs packets if
USE_IPFTF is negotiated in the IKE, then next-header field is ignored
on the recipient, and sent out as 253 (or 0, or whatever, as it is
always ignored on the recipient).
-- 
[email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Thu, 15 Oct 2020 17:20:47 -0400

> On Oct 15, 2020, at 4:48 PM, Tero Kivinen <[email-masked]> wrote:
> 
> Christian Hopps writes:

These are just examples, they fall out of relying on as little state as possible to help debug things. One could have the correct decryption key but not have all the correct configuration in a non-IKE scenario, ...

In any case it's always better to rely on less state where one can. It is almost always more robust. I don't think this is a controversial statement.

> in IKE, I have hard time convincing others.

Ok good, so let's consider re-using an existing number then.

> experimientation and testing.

There is it's officially called "Internet Stream Protocol". Lou could speak more about that I guess.

> always ignored on the recipient).

I still believe an identifier is important for the robust aspects I mentioned above (less state dependent payload identification, aids in packet captures, error logging/mis-configuration identification, yes even zero-configuration receive support which doesn't have to be in the document to still be a feature people want and could be given then).

Additionally, as mentioned previously, not all users of IPsec utilize IKE.

Thanks,
Chris.

---

From: Lou Berger <[email-masked]>
Date: Fri, 16 Oct 2020 09:35:40 -0400

> There is it's officially called "Internet Stream Protocol". Lou could speak more about that I guess.
not that it's critical -- protocol number 5 is both assigned and 
historic.  I'm happy to support it's reuse as co-editor/author of the 
final version of IPv5, RFC1819.

Lou

PS my unicast mail is broken, but I'm reading the list