On reconsideration, I agree with Manav that the NH field will be useful for hardware implementations. Let's keep it.
Thanks,
Yaron
> -----Original Message-----
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> gabriel montenegro
> Sent: Tuesday, May 12, 2009 2:27
> To: Bhatia, Manav (Manav); ipsec@ietf.org
> Subject: Re: [IPsec] Next Header field in WESP header
>
>
> 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
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
