Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-08.txt

From: [email-masked]
Date: Tue, 1 Sep 2009 09:00:02 -0700 (PDT)

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           : Wrapped ESP for Traffic Visibility
	Author(s)       : K. Grewal, et al.
	Filename        : draft-ietf-ipsecme-traffic-visibility-08.txt
	Pages           : 15
	Date            : 2009-09-01

This document describes the Wrapped Encapsulating Security 
Payload (WESP) protocol, which builds on top of Encapsulating 
Security Payload (ESP) [RFC4303] and is designed to allow 
intermediate devices to ascertain if ESP-NULL [RFC2410] is being 
employed and hence inspect the IPsec packets for network 
monitoring and access control functions.  Currently in the IPsec 
standard, there is no way to differentiate between ESP 
encryption and ESP NULL encryption by simply examining a packet. 
This poses certain challenges to the intermediate devices that 
need to deep inspect the packet before making a decision on what 
should be done with that packet (Inspect and/or Allow/Drop). The 
mechanism described in this document can be used to easily 
disambiguate ESP-NULL from ESP encrypted packets, without 
compromising on the security provided by ESP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Sep 2009 12:25:08 +0300

> 	Filename        : draft-ietf-ipsecme-traffic-visibility-08.txt

Found out one more nit in the WESP draft. It now says:

    Flags, 8 bits: The bits are defined LSB first, so bit 0 would be
    the least significant bit of the flags octet.

and then defines flags from MSB first without specifying bit numbers
and those bit numbers based on the picture are 5-7. This is bit
confusing. So I propose that you add the explicit bit numbers to the
descriptions i.e. add "bits 6-7" to version and "bit 5" to
description.

On the other hand your picture is using MSB order, i.e. bit number 0
is the most significant bit, and flags is bits 24-31, so it would make
sense to define bits inside the flags also in MSB order, i.e. change
the text to:
----------------------------------------------------------------------
   Flags, 8 bits: The bits are defined MSB first, so bit 0 would be 
   the most significant bit of the flags octet. 

       2 bits (bits 0-1): Version (V). MUST be sent as 0 and checked
   by the receiver. If the version is different than an expected
   version number (e.g. negotiated via the control channel), then the
   packet must be dropped by the receiver. Future modifications to the
   WESP header may require a new version number. Intermediate nodes
   dealing with unknown versions are not necessarily able to parse the
   packet correctly. Intermediate treatment of such packets is
   policy-dependent (e.g., it may dictate dropping such packets).

       1 bit (bit 2): Encrypted Payload (E). Setting the Encrypted
   Payload bit to 1 indicates that the WESP (and therefore ESP)
   payload is protected with encryption. If this bit is set to 0, then
   the payload is using ESP-NULL cipher. Setting or clearing this bit
   also impacts the value in the WESP Next Header field, as described
   above. The recipient MUST ensure consistency of this flag with the
   negotiated policy and MUST drop the incoming packet otherwise.

       5 bits (bits 3-7): Flags, reserved for future use. The flags
   MUST be sent as 0, and ignored by the receiver. Future documents
   defining any of these flags MUST NOT affect the distinction between
   encrypted and unencrypted packets. Intermediate nodes dealing with
   unknown flags are not necessarily able to parse the packet
   correctly. Intermediate treatment of such packets is
   policy-dependent (e.g., it may dictate dropping such packets).
----------------------------------------------------------------------

I am actually not sure if we have properly defined bit order for IETF
use. In pictures we use MSB bit first numbering, but in some other
places we have used LSB bit numbering (like RFC4306 uses for its
flags).

If you want to keep LSB bit ordering inside the flags then text would
be:

----------------------------------------------------------------------
   Flags, 8 bits: The bits are defined LSB first, so bit 0 would be 
   the least significant bit of the flags octet. 

       2 bits (bits 6-7): Version (V). MUST be sent as 0 and checked
   by the receiver. If the version is different than an expected
   version number (e.g. negotiated via the control channel), then the
   packet must be dropped by the receiver. Future modifications to the
   WESP header may require a new version number. Intermediate nodes
   dealing with unknown versions are not necessarily able to parse the
   packet correctly. Intermediate treatment of such packets is
   policy-dependent (e.g., it may dictate dropping such packets).

       1 bit (bit 5): Encrypted Payload (E). Setting the Encrypted
   Payload bit to 1 indicates that the WESP (and therefore ESP)
   payload is protected with encryption. If this bit is set to 0, then
   the payload is using ESP-NULL cipher. Setting or clearing this bit
   also impacts the value in the WESP Next Header field, as described
   above. The recipient MUST ensure consistency of this flag with the
   negotiated policy and MUST drop the incoming packet otherwise.

       5 bits (bits 0-4): Flags, reserved for future use. The flags
   MUST be sent as 0, and ignored by the receiver. Future documents
   defining any of these flags MUST NOT affect the distinction between
   encrypted and unencrypted packets. Intermediate nodes dealing with
   unknown flags are not necessarily able to parse the packet
   correctly. Intermediate treatment of such packets is
   policy-dependent (e.g., it may dictate dropping such packets).
-- 
[email-masked]