In case it wasn't clear for the earlier WESP discussions, we need this to also work with simple transport mode: i.e. not just transport mode inside tunnels terminating at various infrastructure, and not just in tunnel mode.
The transport nesting from 2401 doesn't give us what this extension proposal does. bs -----Original Message----- From: Brian Swander Sent: Monday, December 07, 2009 10:25 AM To: 'Stephen Kent' Cc: [email protected] Subject: RE: [IPsec] Proposed work item: WESP extensibility 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:[email protected]] Sent: Monday, December 07, 2009 7:46 AM To: Brian Swander Cc: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
