Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

[Tero Kivinen <[e-mail]>]

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).
-- 
[e-mail]