At 10:10 PM +0000 1/5/10, Brian Swander wrote:
I'll resend my message from earlier today that gives a concrete
scenario for why the WESP encryption bit is in charter.
To satisfy the existing charter item, we need a deployable solution,
which entails working with legacy systems that don't support this
functionality yet.
Here's an explicit scenario that requires the encrypted bit for
WESP, fully within the current charter of enabling ESP-NULL
inspection.
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.
Sample policy:
When talking to/from non-WESP capable machines: must do ESP-NULL only
When both peers are WESP capable: do WESP/ESP-NULL most places.
However, where policy requires encryption, do WESP/ESP.
This is where I have a problem with the analysis. If the policy were
that WESP-capable hosts did ESP when then needed to send encrypted
traffic, the flag inn question would not be needed, right?
I don't think we can justify the inclusion of this flag based on the
scenario you described above, because that scenario adopts a
particular local policy that it not required.
Steve
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
