Per my recollection, during the interim last week, Yaron clarified that even though he had made the suggestion to do away with the Next Header field, he did not feel strongly about it.
His point is valid, though: if it is not found to be useful, then the field should not be included. Your point below about Next Header being useful is specially valuable as it is from someone involved in developing these boxes. Gabriel ----- Original Message ---- > From: "Bhatia, Manav (Manav)" <ma...@alcatel-lucent.com> > To: "ipsec@ietf.org" <ipsec@ietf.org> > Sent: Monday, May 11, 2009 4:11:41 PM > Subject: [IPsec] Next Header field in WESP header > > Hi, > > I'd personally like to see the "Next Header" field retained in the WESP > header. > It becomes extremely easy for the ASICs (even off the shelf ones like > Broadcom, > Wintegra, etc) to look at a fixed offset in the packet for a particular byte > pattern and decide on what it needs to do with that packet. By removing the > "Next Header" it becomes quite difficult to do this in the fast path unless > one > has customized ASICs used in their Hardware. > > In our current implementation it is trivial to add a HW filter which says the > following: > > Drop all WESP traffic if its carrying TCP to port 8008 (we could also specify > the source/dest IP) > > This is possible because I know exactly where to look at in the incoming > packet > and decide based on that. > > Is there a strong reason for doing away with the "Next Header" field in the > WESP > header as was suggested some time back? > > Cheers, Manav > > > -----Original Message----- > > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > > On Behalf Of Michael Richardson > > Sent: Wednesday, May 06, 2009 2.42 AM > > To: ipsec@ietf.org > > Subject: Re: [IPsec] Issue #93: Next header value in tunnel > > mode for WESP > > > > Yaron Sheffer wrote: > > > Hi Ken, > > > > > > It seems to me this field is more trouble than it's worth. > > We are assuming > > > that the hardware will be enforcing a very simplistic > > security policy (don't > > > care if it's Tunnel or Transport, don't care if it's a TCP > > SYN or not etc.) > > > and that the hardware is unable to perform anything more > > than extremely > > > basic packet parsing. Both assumptions may well be > > incorrect. And the cost > > > is in complicating the protocol and the endpoint implementations. > > > > Have we received any review yet from companies/individuals > > that actually > > build the hardware involved? (I'm out of that business for 8 > > years myself). > > > > > > _______________________________________________ > > 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
