Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05

2009-07-14 Thread QIU Ying
Regarding the Next Header in section 2, what will be happened if the value of Next Header is zero (i.e. IPv6 Hop-by-Hop option) and the packet is not encrypted? Regards Qiu Ying - Original Message - From: Yaron Sheffer To: ipsec@ietf.org Sent: Sunday, July 05, 2009 3:48 AM

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05

2009-07-14 Thread QIU Ying
Since the zero of next header value is used for HOPOPT already, maybe applying a new value for this intention is better to avoid the confliction. Regards Qiu Ying - Original Message - From: QIU Ying To: Yaron Sheffer ; ipsec@ietf.org Sent: Tuesday, July 14, 2009 3:30 PM Subj

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05

2009-07-14 Thread Grewal, Ken
Thanks Qiu Ying - great observation. We had originally proposed using a bit from the WESP flags (integrity only) for differentiating between ESP-encrypted and ESP-NULL traffic, but changed this to using a value of zero in the next header for efficient encoding, although this is overloading the

[IPsec] I-D ACTION:draft-ietf-ipsecme-roadmap-03.txt

2009-07-14 Thread Internet-Drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Author(s)

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05

2009-07-14 Thread QIU Ying
Hi, Ken Agree that Option 1 is better as it applies lesser new IANA numbers. But in this case, it seems redundancy to copy the value of Next Header field in the ESP trailer to here. How about simply setting the value as ESP here? I think it more meet the original concept of Next Header. Maybe