Actually I'm suggesting to drop it altogether.
Thanks,
Yaron> -----Original Message----- > From: Grewal, Ken [mailto:ken.gre...@intel.com] > Sent: Monday, May 04, 2009 20:43 > To: Yaron Sheffer; ipsec@ietf.org > Subject: RE: Issue #93: Next header value in tunnel mode for WESP > > Hi Yaron, > I am inclined to agree, but wanted to raise this as an option as it was > raised during conversations at the last meeting. > > Are you indicating that we should set this field to be the same value as > in > the ESP trailer, irrespective of tunnel / transport mode? > > Thanks, > - Ken > > > >-----Original Message----- > >From: Yaron Sheffer [mailto:yar...@checkpoint.com] > >Sent: Sunday, May 03, 2009 6:52 AM > >To: Grewal, Ken; ipsec@ietf.org > >Subject: RE: Issue #93: Next header value in tunnel mode for WESP > > > >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. > > > >Thanks, > > Yaron > > > >> -----Original Message----- > >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of > >> Grewal, Ken > >> Sent: Thursday, April 30, 2009 23:39 > >> To: ipsec@ietf.org > >> Subject: [IPsec] Issue #93: Next header value in tunnel mode for WESP > >> > >> All, > >> As we prepare to submit the next revision of the WESP draft, we wanted > to > >> get some discussion / feedback on some open ticket items. > >> > >> Issue #93: Next Header field to provide the value for the tunneled > packet > >> if > >> using tunnel mode > >> > >> In the current traffic visibility draft, we indicate that the next > header > >> value in the WESP header is equal to the next header value in the ESP > >> trailer. > >> Charlie Kaufman suggested that middle boxes may not want to > differentiate > >> between tunnel / transport mode and just get to the payload. > >> i.e. consider providing the tunneled protocol value in WESP next header > >> field in the > >> case of tunnel mode and the WESP offset points to the tunneled payload > >> > >> Pros: easier parsing for intermediary devices > >> Cons: lose consistency between next header in WESP and in ESP trailer - > >> any > >> security concerns? > >> > >> Comments / opinions appreciated... > >> > >> Thanks, > >> - Ken > >> _______________________________________________ > >> 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
