Thanks Yaron - I will capture this as part of the text on packet handling and field validation.
Thanks, - Ken >-----Original Message----- >From: Yaron Sheffer [mailto:[email protected]] >Sent: Friday, May 15, 2009 8:41 AM >To: Grewal, Ken; [email protected] >Subject: RE: IPsecME traffic visibility open item summary > >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
