ipsec September 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility

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

From: Tero Kivinen <kivinen_at_nospam>
Date: Thu Sep 03 2009 - 09:25:08 GMT
To: ipsec@ietf.org


Internet-Drafts@ietf.org writes:
> 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

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). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec