> On Jun 2, 2020, at 10:21 AM, Tero Kivinen <kivi...@iki.fi> wrote:
>
> 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.
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).
> 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.
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.
> 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.
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.
>
> 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.
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.
> 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...
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.
> --
> kivi...@iki.fi
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
