There are a lot of boxes deployed in the field that cant do what you seem to be suggesting.
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. 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. Not many boxes would be able to do that. 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. 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! Cheers, Manav > -----Original Message----- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Tuesday, May 12, 2009 2.31 PM > To: gabriel montenegro > Cc: Bhatia, Manav (Manav); ipsec@ietf.org > Subject: Re: [IPsec] Next Header field in WESP header > > gabriel montenegro writes: > > Your point below about Next Header being useful is specially > > valuable as it is from someone involved in developing these boxes. > > If the box can do IPv6 header processing (which do require similar > offset calculations) to find the WESP header in the first place, then > doing packet length - ICV length (from packet) and get byte from there > is not that complicated and hardware can most likely do that already. > > And I hope nobody is designing new hardware now which cannot do IPv6 > processing... > -- > kivi...@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
