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

Reply via email to