<SNIP!>
> Transport policies for within an organization that want to enable
> intermediary inspection of ESP-NULL non-heurisitically. Organization has a
> mix of version of systems.
At this point I need more details. Specifically, why does an organization
need to inspect ESP-NULL packets? I can think of two good reasons off the
top of my head:
* To appropriately schedule or forward a packet according to latency,
or any other number of diffserv properties.
- Deep-packet inspection for content or other beyond-the-headers
processing.
I've marked the first item with *, and the second with -.
Items marked with * merely requires flow classification. In IPv6 we have a
flow id already, and there are rumblings of a hop-by-hop IPv4 option to do
the same thing here:
http://tools.ietf.org/html/draft-dreibholz-ipv4-flowlabel-11
(Heck, it's even 20 bits!)
Items marked with - require that the payload be in the clear, or (by some
miracle) the inspecting entity has the cryptographic keys.
Items marked with * can use flow labels. Yes it's a host software change,
but quite frankly so is WESP. WESP doesn't do anything in this case an
alternate mechanism cannot do.
Items marked with - will benefit greatly from WESP IF (and only if) you
believe heuristics to be untenable, but encrypted WESP support won't help
here at all. Furthemore, a working flow label deployment and flow labelling
policy could make what were heuristics into completely deterministic
processing.
There's vague talk about deployability and future directions. Please show me
some concrete examples supporting WESP with encrypted packet support. I
suspect such examples will most likely either require the whole packet text
(i.e. marked with -) or just enough data to identify a flow (i.e. marked with
*).
Thanks,
Dan
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
