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

[Tero Kivinen <[e-mail]>]

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

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