Hi Dan, I think the main motivation for using ESP and providing a wrapper was so we do not have to reinvent the wheel / redo all the work that has been done already. Starting off from scratch on a new protocol would have meant a larger workload and this item was meant to be a simple wrapper to provide the desired functionality.
I do recall that someone else had brought up modifying AH earlier also, but as ESP already provided everything we needed, including NAT-T support, and we had two existing I-Ds as a starting point, we selected this route. Thanks, - Ken >-----Original Message----- >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >Of Dan Harkins >Sent: Wednesday, January 06, 2010 4:04 PM >To: Grewal, Ken >Cc: ipsec@ietf.org; Paul Koning; Stephen Kent >Subject: Re: [IPsec] Traffic visibility - consensus call > > > Hi Ken, > > No one responded to my suggestion so I'll suggest it again below. > >On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote: >[snip] >> The bottom line is that in order for a network appliance (Trusted >> Intermediary) to offer critical network services (IDS/IPS/DPI/Access >> Control) in IPsec environments, it needs to know if a given IPsec >packet >> is encrypted or not in a deterministic manner and this is within >scope. >> WESP is offering this determination on a per packet basis. > > That is a clear definition of the problem: a TI must be able to >determine whether a given IPsec packet is encrypted or not. > >[snip] >> Some argue that we should use WESP for NULL traffic, mandating ESP for >> encrypted traffic...AND ensure that ESP is NEVER used for NULL >encryption >> within a given domain / environment. How does an intermediate device >know >> that this policy is being enforced? What if ESP is still being used >for >> ESP-NULL and encrypted traffic? If this is the case, we are back to >where >> we were/are today - no way to tell if ESP payload is encrypted or not. > > The intermediate device knows this because it is under the same >policy domain as the endpoints that have agreed to do WESP. If he's not >in the same policy domain then he has no assurance that the endpoints >will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL >cipher, so this box in the cloud is out-of-luck again and WESP doesn't >help. Unless, of course, WESP is really a trojan horse to deprecate ESP >and force everyone to use WESP always but you have said that's not the >case. > > So now my suggestion again. If you're going to specify a new protocol >and require endpoints to implement it then why not just make a new >IPsec protocol that is a NAT-friendly way of doing per-packet integrity >protection? Don't try to "wrap" ESP packets. That way the middlebox >knows >that when it sees this new protocol that it is not encrypted and when it >sees ESP it knows it is encrypted (it knows that ESP is not using NULL >encryption because policy has disallowed that). We could even think >about >deprecating ESP-NULL in favor of this new protocol. This would be an >architecturally cleaner way of solving the problem you clearly described >above. IKE can negotiate the new protocol, in transport- or tunnel-mode, >negotiate an algorithm to use to provide integrity protection, and >establish an authenticated and shared key to use with the algorithm. So >what's the problem with this suggestion? > > regards, > > Dan. > > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
