Hi Ken, Tero mentioned that two more fields must be zero when the payload is encrypted. Is this covered by any of the open issues?
Thanks,
Yaron
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Grewal, Ken
> Sent: Friday, May 15, 2009 17:19
> To: [email protected]
> Subject: [IPsec] IPsecME traffic visibility open item summary
>
> All,
> In an attempt to get consensus and closure on some of the open tickets for
> traffic visibility, I am providing the following summary. I look forward
> to your feedback...
>
> #84: Wesp scope and applicability to encrypted data. Agreed that we will
> use Next Header value of zero to denote packet payload is encrypted.
> Should be closed?
>
> #85: units for header / trailer len. Updated in rev 02 - Gabriel is owner
> and needs to update / close ticket.
>
> #88: UDP encap diagram is wrong - fixed in rev 02. Additionally, Yaron's
> comment on updating reference to 4306 from 3947 - will address in next
> rev.
>
> #89: Version handling - added some text, but need to add additional text
> on how this is treated by intermediate devices, as well as recipients -
> see discussion on ML.
>
> #90: Shorter WESP negotiation using notifications - added this to rev02 -
> all agree that this is the right approach?
>
> #91: Next Header field should not be optional for ESP-NULL. Added text to
> rev 02.
>
> #92: Clarify how to treat the flags. This is similar to #89 and will
> clarify further in next rev.
>
> #93: Next header to provide value of tunneled packet. Some comments on ML
> indicate that Next Header value in WESP should be same as Next Header
> value in ESP trailer. This provides consistency and aids easy validation
> by recipient - need to add text to indicate consistency between tunnel /
> transport mode.
>
> #104: Handling malformed fields in WESP header. This is similar to Next
> header corruption and will add text to ensure recipient validates these as
> per suggestions on ML.
>
> Side issue: Between rev-01 and rev-02, moved WESP flags to beginning of
> WESP header. Rationale was to place flags first, so any packet format
> changes in the future can be accommodated by checking the flags and then
> inferring the subsequent formatting. Offline comment prefers the flags to
> be at end of WESP header, as per rev-01 of draft. Any preference from
> others? Raise a separate ticket for this?
>
>
> Thanks,
> Ken
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
