Subject: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number.

From: Christian Hopps <[email-masked]>
Date: Mon, 1 Jun 2020 16:20:35 -0400

Dear ipsecme Chairs,

This request is inline with the guidelines as set forth in RFC7120 (https://tools.ietf.org/html/rfc7120)

I would like to request early allocation of the IP protocol number [A] used for the ESP payload identifier for IPTFS (suggested value is 144 or next available) as documented in https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 [B]

This will aid in the deployment of an experimental implementation of the documented protocol as well as testing inter-operability with other expected implementations. [C], [D]

In addition to these RFC7120 reasons, the topic was raised on the WG list and discussed in previous meetings. The discussions highlighted that early allocation was a good choice as it allowed for the temporary assignment and an extended period of time for adequate review (and explanation if needed) of this allocation prior to publication requested being reached.

Thanks,
Chris.

[A-D] - refer to https://tools.ietf.org/html/rfc7120#page-4 section 2a - 2d.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 2 Jun 2020 17:21:07 +0300

Christian Hopps writes:
> I would like to request early allocation of the IP protocol number
> [A] used for the ESP payload identifier for IPTFS (suggested value
> is 144 or next available) as documented in
> https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 [B] 
> 
> This will aid in the deployment of an experimental implementation of
> the documented protocol as well as testing inter-operability with
> other expected implementations. [C], [D] 
> 
> In addition to these RFC7120 reasons, the topic was raised on the WG
> list and discussed in previous meetings. The discussions highlighted
> that early allocation was a good choice as it allowed for the
> temporary assignment and an extended period of time for adequate
> review (and explanation if needed) of this allocation prior to
> publication requested being reached. 

I am bit concerned about this. First of all, as far as I understand
for IPsec we do not need real IP protocol number, as the number we are
using is never going to appear anywhere in the actual IP packet
header, it only appears in the ESP trailer Next Header field.

Note, that the ESP Next Header field is not exactly same as IP
Protocol Numbers, it is:

   The Next Header is a mandatory, 8-bit field that identifies the type
   of data contained in the Payload Data field, e.g., an IPv4 or IPv6
   packet, or a next layer header and data. The value of this field is
   chosen from the set of IP Protocol Numbers defined on the web page of
   the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates
   IPv6, and a value of 6 indicates TCP.

i.e., it is separate set of numbers, which happen to mostly match what
IP protocol numbers use, but we also interpret some values
differently, for example value 59 (IP protocol no next header) is used
to indicate dummy packet etc.

We could easily use similar trick than what we use for dummy packets
for this too. Also there is warpped ESP which would allow us to use
that, which would again allow us to do things without allocating new
IP protocol number.

We had some discussion about this in the mailing list earlier, but I
didn't think that there was really a final result from that discussion
(or I might be remembering wrong, as I didn't have too much time to
participate that discussion at that time).

The reason I am concerned is that I was there when we wanted to get
the Wrapped ESP IP protocol number, and there was quite a lot of
discussion going on at that time, and it was not just we send request,
and we get the number. Of course at that point I also supported
proposal which did not require new IP protocol number, so for me the
problems getting IP number was for my favor :-)

Anyways before we commit resources and try to get the IP protocol
number I want to make sure we actually need it, and we have good
responses to why we cannot do it with the other ways I presented
above.

I would assume those questions are going to be asked from chairs or
area directors during the process anyways, so we need to have good
answers to them ready (and for me it would be quite hard to explain
why we cannot use warpped ESP, or dummy packet trick as I think we can
do those and we do not need IP protocol number).

Note, that if the answer is going to be that we want to use this also
when we are not using IPsec, then this is even bigger can of worms, as
that would most likely mean that this work does not belong to the
IPsecME working group, but should be part of completely different
area...
-- 
[email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Tue, 2 Jun 2020 11:56:48 -0400

> On Jun 2, 2020, at 10:21 AM, Tero Kivinen <[email-masked]> wrote:
> 
> Christian Hopps writes:
>> Dear ipsecme Chairs,
>> 

We would if people want to re-use the framing outside of IPsec. This is not a requirement for us, but it's something to consider none-the-less  (more below on that though).

> to indicate dummy packet etc.

Re-purposing is good backup option we have available to us if for some odd reason we cannot ultimately retain our early allocation. I don't think this should stop us from getting an early allocation even if we were to end up choosing this option though.

> that, which would again allow us to do things without allocating new

I did talk about why wrapped was not an optimal solution in an earlier thread, and received an agreement with my reasoning there. In short it still has a next-header field requirement so we are back to where we started, and we lose bandwidth to boot.  I think the repurposing of a protocol number as a backup solution is better than trying to use WESP.

> responses to why we cannot do it with the other ways I presented

This should not be that big of a deal if we have justification, which we do, but this is one reason for the early allocation.

Doing an early allocation allows us to move forward, and in the end if we cannot get the allocation or it becomes too onerous we could then re-use an existing number as a backup. So this shouldn't be a big drain on the WG either way.

Getting the early allocation also will allow 2 years for people who want to to experiment with non-IPsec uses (the E in IETF :) If something comes of that then it will help provide further justification for making the allocation permanent.

Its worth noting that the basic header associated with the proposed IP protocol number is a single sub-type octet which defines what follows. It places no restrictions on what follows that sub-type octet, and so it is *very* easy to re-use this protocol number in the future. It is much more reusable than WESP, for example. I think this should also help answer external objections if they are raised.

> IPsecME working group, but should be part of completely different

As I mentioned above, people have already expressed interest in possibly using the IPTFS framing outside of IPsec for some of its positive non-IPsec properties. This doesn't mean we have to boil the ocean and standardize the framing outside of IPsec, it just means we should be considerate about the possible re-use while we do our work.

Thanks,
Chris.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Jun 2020 16:40:46 -0400

> header, it only appears in the ESP trailer Next Header field.

Yes, we did have this conversation.
We know that it can't be a number that IANA might re-use for a an actual
protocol number.
So it could somehow be a re-use of something that is obsolete, historic, or
just contradicted with ever being used with IPsec.  (If I had to pick a such
a number, I'd use AH's number)

    > participate that discussion at that time).

My memory is that most people didn't think that protocols numbers were so
scarce that the cost exceeded the possible confusion.   Christian is asking
for one number, not ten.

    > problems getting IP number was for my favor :-)

Does anyone use Wrapped ESP?
Can we just mark that as historic now :-)

    > IPsecME working group, but should be part of completely different

Let's assume that we might want to use this protocol with another secure
tunnel protocol which was not ESP.  But, not in the clear over the Internet.
(Think: QUIC, Wireguard, OpenVPN)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Steffen Klassert <[email-masked]>
Date: Sun, 7 Jun 2020 11:00:00 +0200

> As I mentioned above, people have already expressed interest in possibly using the IPTFS framing outside of IPsec for some of its positive non-IPsec properties. This doesn't mean we have to boil th…

I'm one of those who was interested in a different usecase for
the IPTFS payload. My plan was to present about that at the
Linux IPsec workshop this year. Unfortunately, this workshop
was canceled because of COVID-19 outbreak, so I never got
feedback about the idea. Below is the Abstract of this presentation
that sketches the idea (just for the case somebody finds it usefull).

- An alternative usecase for IPTFS_PROTOCOL payload type tunnels.

  This alterative usecase tries to solve the 'small packet' tunneling
  problem. Sending small packets over a tunnel usually creates quite
  a lot of overhead, as each packet needs to get it's own tunnel header
  etc. For IPsec, the situation is even worse as a cpu intensive crypto
  operation has to be applied for each of these small packets. With the
  IPTFS_PROTOCOL payload type, we could group small packets and send
  them into one big packet over the tunnel. This can avoid tunneling
  overhead because we need only one tunnel header for multiple packets.
  Also this method would be very data and instruction cache effective
  because multiple packets are processed together. The good thing is that
  the Linux forwarding path can already provide packets chains (GRO),
  so we would just need to take these packets chains and put them
  into big tunnel packets with IPTFS_PROTOCOL payload type. As a side
  effect, having IPTFS_PROTOCOL as a general purpose tunnel payload,
  it might be easier to argue for a new IP protocol number allocation.

Steffen

---

From: Michael Richardson <[email-masked]>
Date: Sun, 07 Jun 2020 21:43:41 -0400

Steffen Klassert <[email-masked]> wrote:
    > problem. Sending small packets over a tunnel usually creates quite a
    > lot of overhead, as each packet needs to get it's own tunnel header
    > IPTFS_PROTOCOL payload type, we could group small packets and send them
    > into one big packet over the tunnel. This can avoid tunneling overhead
    > because we need only one tunnel header for multiple packets.  Also this
    > method would be very data and instruction cache effective because
    > multiple packets are processed together. The good thing is that the
    > Linux forwarding path can already provide packets chains (GRO), so we
    > would just need to take these packets chains and put them into big
    > tunnel packets with IPTFS_PROTOCOL payload type. As a side effect,
    > having IPTFS_PROTOCOL as a general purpose tunnel payload, it might be
    > easier to argue for a new IP protocol number allocation.

Does your use case include situations where this is not an IPsec tunnel?

Tero's point was that when we are putting things into ESP, that we
effectively get an IPsec-specific protocol number space, and so maybe we
don't need a first-class protocol number.

---

From: Steffen Klassert <[email-masked]>
Date: Mon, 8 Jun 2020 13:05:02 +0200

> Does your use case include situations where this is not an IPsec tunnel?

My main usecase would be an IPsec tunnel, but the same can work
for other tunnel types too. If we have an IP protocol number,
it is just easy to use it outside of IPsec world, but I don't
have a strong opinion on that.

Steffen

---

From: Lou Berger <[email-masked]>
Date: Mon, 8 Jun 2020 13:24:31 -0400

> have a strong opinion on that.

FWIW  Ethernet TFS (802.1AEdk) is taking an approach that allows for 
this type of operation  as some there want to explicitly allow the E-TFS 
framing separated from  MACsec encryption...

Lou

>
> Steffen
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Christian Hopps <[email-masked]>
Date: Thu, 25 Jun 2020 06:24:18 -0400

Hi Tero,

I believe the discussion has died down again and we have answers to the questions you are concerned will be raised by the other reviewers of the request (Yoav and Benjamin for the early allocation), to wit:

  1) WRAP still requires a next-header/protocol number. Additionally it would reduce bandwidth, is not widely implemented, and ultimately is not a great fit as it's trying to solve a different problem (allowing more packet inspection).

  2) We could technically overload/re-use an existing IP protocol number that we assume will never be used as an ESP payload, but this is a sub-optimal solution as it disallows the re-use of IPTFS framing outside of ESP. Ultimately this can serve as a backup solution that aligns with (and thus supports) this (temporary) early allocation request.

So can we move forward with the early allocation request?

Thanks,
Chris.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jun 2020 12:15:46 -0400

Christian Hopps <[email-masked]> wrote:
    > 1) WRAP still requires a next-header/protocol number. Additionally it
    > would reduce bandwidth, is not widely implemented, and ultimately is
    > not a great fit as it's trying to solve a different problem (allowing
    > more packet inspection).

    > 2) We could technically overload/re-use an existing IP protocol number
    > that we assume will never be used as an ESP payload, but this is a
    > sub-optimal solution as it disallows the re-use of IPTFS framing
    > outside of ESP. Ultimately this can serve as a backup solution that
    > aligns with (and thus supports) this (temporary) early allocation
    > request.

    > So can we move forward with the early allocation request?

I would agree.  The WG should go ahead with the early allocation request.
It still needs AD approval, and then goes to the IESG.

I think that the WG has agreed:

1) we need a number.
2) we'd like the number via early allocation
3) we have rough consensus that there are a set of protocol numbers
   that we *could* reuse, and I think that we could make a list
   of protocol numbers we know we can *not* reuse.
   (4,6,17 would start the list we can not use)

so let's put the allocation request in, and let's let the IESG decide how
much they want to optimize the protocol space.

I think that we have consensus that our need for uniqueness is not as strong
as other users.  BUT simplificity of accounting and coding would make it
simplest if the number was not something already in use.

But, we are not out of protocol numbers, and I think that if it comes to recycling
numbers, that maybe there are many low-hanging fruit as candidates.
[13-16,18-26 comes easily to mind]
Also, if the IESG wanted to mark WRAP as returned, that's a different
discussion as well.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jun 2020 12:41:45 -0400

> [13-16,18-26 comes easily to mind]

If I had to pick something, though, I'd pick 57, SKIP :-)

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 Jun 2020 13:43:43 -0400

I really think it makes most sense to push put in the early allocation 
request.  This is a valid long term use case.  There's no real shortage 
of IP numbers and IANA is continuing to assign them.  Also there's also 
a slew of them that can be reclaimed if/when they do become scarce.  I 
can even vouch for giving up one (v5) if/when needed  - it's already 
marked historic;-)

Lou