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
