No hat. At 5:56 PM +0000 1/6/10, Brian Swander wrote: >But that doesn't give us any path to actually do encryption (in environments >with legacy systems) - hence the proposal is untenable.
That doesn't make sense: it is *exactly* the same path as we have today. WESP-as-envisioned gives us one extra capability; WESP-as-it-is-today gives us two. The "path to actually do encryption (in environments with legacy systems)" is to use ESP exactly as it is being done today by dozens of vendors, including you. >I'd argue it therefore doesn't satisfy the charter item. The charter item is >a deployable mechanism that lets intermediaries inspect ESP-NULL when present. > This charter item surely shouldn't mandate that we can now no longer use >encrypted ESP at all. Please don't reduce this to absurd straw men. The charter item is quite clear: A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. WESP-over-ESP-NULL-only fulfills that charter item. WESP-as-it-is-today does it as well, but adds additional features and extensibility. The question in this thread is whether to back down to WESP-over-ESP-NULL-only. >Clearly we need a solution that also lets us use encrypted traffic where >needed, but not break inspection of integrity only traffic. How do we meet >that with your proposal below? As it is done today, and adding in WESP-over-ESP-NULL-only. >We must make sure that we have a solution that is deployable and useful in the >real world. Really, you think so? :-) --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
