> On Oct 15, 2020, at 4:48 PM, Tero Kivinen <kivi...@iki.fi> wrote: > > Christian Hopps writes: >> We are defining the payload in this document, the payload is meant >> for ESP. ESP has a payload identifier why can't we use it? > > If that is only possible value the next-header field can have as all > packets of the Child SA which has been negotiated with USE_IPTFS then > what is the point of allocating number that is not needed. You can > simply say that next payload field will be transmitted as 0, and > ignored on the recipient as you already know the format packet inside > ESP because it was negotiated in the IKE. > >> It feels like the clean KISS solution to me. Yes, we are doing IKE >> negotiation, but using the designed for payload identifier also >> allows the payload to be identified in non-IKE scenarios (packet >> captures, error logging, etc..), therefor it's not just KISS it's >> also more *robust* and thus I believe a better design. > > So you want to allocate completely new protocol number from the 8-bit > registry, just so that you can print it out in the error logs and > auditing, instead of putting (use_ipftf ? "iptfs" : protocol number)? > > Packet captures does not really help as ESP content is encrypted, and > most implementations do not really allow easy way of printing out the > traffic keys for wireshark etc use, and anyways wireshark has this > decode as XXX option where you can force it to decode it with whatever > protocol you think is inside, regardless whether there is protocol > number matching.
These are just examples, they fall out of relying on as little state as possible to help debug things. One could have the correct decryption key but not have all the correct configuration in a non-IKE scenario, ... In any case it's always better to rely on less state where one can. It is almost always more robust. I don't think this is a controversial statement. >> I think your main objection is over actually making an IP protocol >> number allocation. > > Actually doing early allocation. > >> If that's what it is then let's focus on that point. It may be >> easier to make progress that way. > > I need to justify why the WG thinks we need this done now, and why > this is going to be useful, and why this can't be done in other ways. > > If I myself think it would be easier to do this by just negotiating it > in IKE, I have hard time convincing others. Ok good, so let's consider re-using an existing number then. > >> For example we could switch to our backup solution and re-use an >> existing IP protocol number which would never be carried in ESP >> (e.g., IPv5). I feel it's a bit less elegant, but still workable, >> and leaves us with the KISS/more robust outcome. > > I do not think there is IP protocol number for IPv5, but if you really > want to have protocol number, why not use 253 that is reserved for > experimientation and testing. There is it's officially called "Internet Stream Protocol". Lou could speak more about that I guess. > This allows you to do your testing now, and you can write your draft > saying that as all payloads inside the ESP will be iptfs packets if > USE_IPFTF is negotiated in the IKE, then next-header field is ignored > on the recipient, and sent out as 253 (or 0, or whatever, as it is > always ignored on the recipient). I still believe an identifier is important for the robust aspects I mentioned above (less state dependent payload identification, aids in packet captures, error logging/mis-configuration identification, yes even zero-configuration receive support which doesn't have to be in the document to still be a feature people want and could be given then). Additionally, as mentioned previously, not all users of IPsec utilize IKE. Thanks, Chris. > -- > kivi...@iki.fi >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
