0 - option data does not change en-route. This option is included in the WESP ICV computation.
We'll be using this flag, so this option will always be integrity protected. I'm not sure what you mean by effecting key distribution. In the integrity only case, the intermediaries can still see into the packet. In the fully encrypted ESP case, only the WESP extension will be visible, and the intermediaries will have to trust the end systems to do the correct marking. If that is not acceptable to a given deployment, the customer always has the policy option to disable this, and just have the end systems send fully encrypted packets thru the now totally blind intermediaries like we have today. bs -----Original Message----- From: Stephen Kent [mailto:k...@bbn.com] Sent: Monday, December 07, 2009 7:46 AM To: Brian Swander Cc: ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: WESP extensibility Brian, I wasn't sure, form your brief description, whether you envisioned any crypto protection for this version of WESP. If not, then this added info is not protected and might be modified en route. This seems like a possibly dangerous feature, as it says that we are causing an intermediate system (e.g., a firewall) to make decisions on passing packets based on unauthenticated info. If the WESP data were protected it would raise questions about how we effect key distribution, and why this form of SA nesting is more attractive than the nested SA support that was pulled from IPsec as we went from 2401 to 4301. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
