Bhatia, Manav (Manav) writes: > There are a lot of boxes deployed in the field that cant do what you > seem to be suggesting.
Those deployed boxes will need updates anyways, as they do not support WESP either... > If we are to pick up the "Next Header" from the ESP trailer then we > need to parse the entire packet with the variability in the ICV > length. Note, that if you want to have port numbers, you still need to do variable offset based on the IV length also. > This would entail storing the entire IPv4/Ipv6 packet > (coming at line rate) in the silicon's buffer which would need to be > really large. Yes. With ethernet 1500 bytes is normally enough though. Might be different situation if IPv6 jumbograms are used. > Not many boxes would be able to do that. I think most of the firewall / security processor type chips I know do that anyways (most of those are chips doing IPsec, thus they are bit more powerful than the very basic chips). Can you list some (new) chips that cannot access the full packet? > However, if we specify the "Next Header" in the WESP header than > most HWs capable of deep inspecting the first 128 bytes would be > able to discern the packet. That might not be enough for IPv6, and suddenly noticing at that point that you need more data could make HW quite complex. > Is there an issue in keeping "Next Header" in the WESP header? I see > an advantage in doing so. Would like to hear arguments against it! I think the most of the concerns were bacause then we have two Next Header fields, and there could be security concerns because of that. On of the options would of course then be to get rid of the Next Header field at the end, and only have that in the WESP header. Or we can mandate that recipient IPsec node MUST drop the packet if next header field in the WESP header and the next header field in the end are different. Then there is also question what if the next header field in the WESP header is 0, should the recipient IPsec node drop the packet if packet was ESP-NULL and still had next header field in WESP header of 0? I am not really strongly against the next header field in the WESP header, I am just sure we have good reasons to duplicate data which might cause security implications before we do that. I am not fully convinced that the cannot get the next header field from the end is good enough reason for adding possible security problems and more complicated protocol. Especially when we are talking about new HW designs coming after WESP is specified. If old HW design can be made to understand WESP then it most likely is already one of those more complex security processor type things which do get full packet anyways. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
