> > 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...
I had meant that there are boxes currently deployed in the field which would have HW capable of only looking at the fixed offsets. SW is a commodity item and can always be upgraded. If you have Next Header in the WESP header then some bit of filtering (at least at the protocol level) can still be done without upgrading the HW. > > > 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. I am talking about routers and switches here. Their main job is not to deep inspect the packets but to route/switch them. Filtering is a capability added to them and most of them would not look at the entire 1500 bytes to figure out the contents of the packets (they're not even meant to do that). As I stated earlier, most would pick up the first 128 or so bytes and filter based on that. > > > 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). That's the disconnect then. I am talking about routers/switches where we might want to deep inspect the packet for different QoS/Policy reasons. > Can you list some (new) chips that cannot access the full packet? You can look at Broadcom and Wintegra. I could be mistaken but I don't think they read the *entire* packet for content aware filtering. You can contact me offline if you want more details on the specific chipset(s) I am referring to. > > 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. This is mentioned in the draft. > > 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? Yup, I thought we were clear on this; patently, I was mistaken ;-) Next Header of 0 implies that the packet uses encryption and the intermediate nodes MUST not attempt to read them. If the end node finds that this isn't true, then it MUST drop the packet. > > 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. Point well taken. > > 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. Not really. Most network processors have a capability of defining user defined fields (UDFs) which the chip looks at in the incoming packet. Using that it becomes trivial to implement and support WESP without any HW change. This to me is a big reason why we must have the Next Header in the WESP header. A compliant implementation can trivially check the sanity of the Next Header field before accepting the packet and this doesn't really sound like a security hole to me (unless I am missing out on something!). Cheers, Manav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
