> On Nov 29, 2019, at 8:13 AM, Valery Smyslov <smyslov.i...@gmail.com> wrote:
>
> Hi Chris,
>
>>> 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.
>
> I envision a lively discussion with INT folks if we ask them for a "fake"
> protocol number :-)
I would not choose to refer to it as a fake protocol. The field is defined as
an IPv4 or IPv6 protocol value to identify the ESP payload. IPsec/ESP is *the*
standard for encrypting IP traffic so this field has a valid claim to make on
that number space. Just b/c it may not (but see next point) be used outside of
IPsec/ESP doesn't mean that IPsec should not be able to allocate a number from
it.
>
>> 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.
>
> Please, elaborate.
The IP-TFS payload format allows for any-sized IP packet to be encapsulated
inside an MTU sized outer header. Thus something like a GRE tunnel (with
sequence numbers) with PMTU size-limited packets would not limit the inner
payload packet size to the PMTU of the GRE tunnel. I'm not proposing this right
now, but it's not hard to envision this use in the future, especially if IP-TFS
is widely adopted by vendors.
>
>> 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
>> :)
>
> It's a strange use case. Both peers must support IP-TFS, but it is used only
> in one direction, so its usefulness
> is limited (you can gain quite a lot information from timing of return
> packets). Do we really need to complicate
> things to allow such asymmetric use case? BTW, you cannot negotiate it with
> your current spec :-)
I do not think this is strange, consider uni-directional data streams, e.g.,
telemetry.
>> 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.
>
> I'm still not sure that it's really needed.
>
>>> 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.
>
> Color me unconvinced. Debugging is a local matter and should not be reflected
> in the spec.
ICMP echo request/reply? :)
More apropos, adding things to a protocol to make it easier to deploy/debug is
not uncommon, we certainly have examples of this in routing (e.g., host
identifier TLV in IS-IS etc)...
If this were the only reason for using the next header field I'd say the case
is not strong for keeping it, but we still have the uni-directional CC case, so
this second use doesn't cost much IMO.
Thanks,
Chris.
>
> Regards,
> Valery.
>
>> Thanks,
>> Chris.=
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
