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. > 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. > 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. 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). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
