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. > 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. > > 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... > -- > kivi...@iki.fi > > _______________________________________________ > 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
