Hi Russ, > My point is that the end system does not need the information in the > WESP header to properly handle the packet for the supported > application. The additional information is being exposed to allow > middle boxes to make various checks. The end system can > ensure that the > exposed information was correct so that middle boxes were not > spoofed. > An extended ICV is not necessary to perform this type of check if the > information is limited to the payload offset and such. An > ICV is only > needed if WESP carries information that cannot be easily checked by a > process that knows the crypto algorithms that are in use. I'm > challenging the need for such information.
One use case could be when you want to prioritize processing certain ESP-NULL packets (most routing applications for instance mandate the use of ESP-NULL as routing is not concerned with confidentiality) over the other. The HW computes the ICV, determines everything is correct and hands over the packet to the IPSec engine. The IPSec engine, briefly inspects the WESP header (and it knows its correct because it passed the preliminary ICV validation check) and looks at the right offsets and depending upon the kind of packet it is, places it in the appropriate queue. With WESP the HW knows the exact offsets it has to look at to figure out the information it needs and can be done in the fast path. OTOH, if we don't include the WESP header in the ICV, then the IPSec engine has to process each packet completely, verify that the WESP header is indeed correct and matches with whats carried inside the packet, before it can do any further processing. This can take up some time, which may be an issue for applications that need faster processing (a protocol like BFD for instance). I currently don't see applications that may need this kind of expedited processing, but the WESP design should not preclude development of such applications/features. However, if folks feel very strongly about not including WESP fields in the ICV, then I would take a back seat and grudgingly concede to it .. Cheers, Manav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
