Not wearing any hat: 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. > >Only with the WESP encrypt bit can intermediaries distinguish what is going on >here, and still enable the uplevel systems to do full encryption where needed. > I.e. if they see ESP, it must be ESP-NULL. If they see WESP, then they must >leverage the encrypt bit to see what to do. > >Hence we need to keep the encrypted bit to satisfy the current WESP charter >item.
That policy makes sense if you assume that WESP covers encrypted ESP. If WESP only covers unencrypted ESP, the policy would be: When talking to/from non-WESP capable machines: must do ESP-NULL only. When both peers are WESP capable: do WESP/ESP-NULL. This is exactly what was envisioned when the WG chartered the work item. That is, the presence of WESP does not affect policy about encryption. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
