> On Nov 28, 2019, at 8:49 AM, Valery Smyslov <smyslov.i...@gmail.com> wrote:
>
> 2. I don't think new IP protocol number is needed at all. Since SA is created
> with IKEv2,
> it is always known whether it is IPTFS SA or ordinary SA, so "Next
> Protocol"
> field in ESP trailer is redundant and can be filled in with arbitrary
> value (say zero).
> If a new protocol number is allocated, it will never appear in any network
> header
> except for encrypted ESP trailer, still it will occupy a codepoint and
> some middle-box
> vendors will probably try to figure out what to do with it (nothing),
> adding some confusion.
> Moreover, I suspect that an idea to allocate a codepoint from rather
> limited resource
> (only 255 are available and more than half of them is already allocated),
> that will never
> appear in any network header and in reality is not needed, will meet a
> negative reaction from
> INT area guys. So, I think we should not go this way and just use zero (or
> other value)
> as a filler for "Next Header" field.
I read part of the above as more an argument for decoupling the ESP next header
number from IP protocol number space, and not so much as a lack of need for a
unique payload identifier for the ESP next header field. This might work if we
really want to do this (i.e., create an ESP payload registry separate from the
IP protocol numbers), but honestly I think it may be overkill given there are
plenty of IP protocol numbers available, and we only need 1 protocol number
which we can re-use later if need be. You may be right that 1/2 of the numbers
are allocated; however, at least one is deprecated and others could be
deprecated (i.e., there's so little pressure on this registry that deprecating
unused numbers just hasn't been something worth doing AFAICT). With all that
this represents 38 years of allocations. I think we just need to make a clear
case for the use, and that we wont keep coming back for more is all.
Additionally, I'm not sure that we should be so quick to say that the IP-TFS
payload would never be used outside of ESP; as was pointed out by Michael using
this payload does solve the PMTU issue with (IPsec) tunnels, it could be
re-used for this purpose outside of ESP as well.
The next-header value is not always redundant, the use case where IP-TFS is
enabled in only one direction with congestion control enabled requires being
able to differentiate IPv[46] packets from IP-TFS CC information which is now
sent in-band in the return direction. The CC information was moved in-band out
of IKEv2 from the original -00 document based on comments from the WG (and I
agree is a much better solution :)
So, I think we need to stick with explicitly identifying the payload inside
ESP. Using the next-header field feels like the correct way of doing this;
however, I haven't looked at ESP wrap yet. I do have concerns (which Tero also
mentioned at the mic) that it might not be widely implemented.
Possibly re-using the payload type outside of ESP someday is an additional
argument for doing the least-disruptive thing and just allocating an IP number.
We don't even need a *new* IP protocol number, we could re-use a deprecated IP
protocol number. This seems like a nice option to look into.
> 7. I don't think that late-enabling of IP-TFS described in section 2.4
> is really needed. It adds unnecessary complexity and somewhat contradicts
> to what is stated in section 2.3.
Having the late-enable could be useful for debugging tunnels during bring-up.
This does rely on having a way to identify the payload, but as mentioned above
this isn't the only thing that relies on that. It didn't add much complexity to
my code, but I'm certainly curious on other opinions on this.
Thanks,
Chris.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
