Subject: [Ipsec] ICV calculation

From: Mahendra <[email-masked]>
Date: Wed, 11 Apr 2007 17:05:29 +0530

Hi,

       If we have only EOL (end of option list) in the IP packet, then there
will be a padding of 3 bytes. Should this padding be considered while
calculating ICV?

Regards,

Mahendra

****************************************************************************
***********

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it! 

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Mahendra <[email-masked]>
Date: Wed, 11 Apr 2007 18:15:51 +0530

Hi,

    I think I haven't described my prob correctly.

 I am speaking about AH protocol in which it authenticates the outer 

IP header also. In this outer IP header if we have IP option as EOL, then 

there will be a padding of 3 bytes in the IP header itself. Should 

this padding in the IP header should be considered while calculating 

ICV?

Regards,

Mahendra

From: Mahendra [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2007 5:05 PM
To: [email-masked]
Subject: [Ipsec] ICV calculation

Hi,

Regards,

Mahendra

---

From: Dan McDonald <[email-masked]>
Date: Wed, 11 Apr 2007 09:07:05 -0400

On Wed, Apr 11, 2007 at 06:15:51PM +0530, Mahendra wrote:
>  I am speaking about AH protocol in which it authenticates the outer IP
> header also. In this outer IP header if we have IP option as EOL, then
> there will be a padding of 3 bytes in the IP header itself. Should this
> padding in the IP header should be considered while calculating ICV?

4302 and its predecessor describe this case:

3.3.3.1.1.2.  Options

   For IPv4 (unlike IPv6), there is no mechanism for tagging options as
   mutable in transit.  Hence the IPv4 options are explicitly listed in
   Appendix A and classified as immutable, mutable but predictable, or
   mutable.  For IPv4, the entire option is viewed as a unit; so even
   though the type and length fields within most options are immutable
   in transit, if an option is classified as mutable, the entire option
   is zeroed for ICV computation purposes.

A1.  IPv4 Options

   This table shows how the IPv4 options are classified with regard to
   "mutability".  Where two references are provided, the second one
   supercedes the first.  This table is based in part on information
   provided in RFC 1700, "ASSIGNED NUMBERS", (October 1994).

               Opt.
    Copy Class  #   Name                       Reference
    ---- ----- ---  -------------------------  --------
    IMMUTABLE -- included in ICV calculation
      0   0     0   End of Options List        [RFC791]
      0   0     1   No Operation               [RFC791]
      1   0     2   Security                   [RFC1108] (historic but
                                               in use)
      1   0     5   Extended Security          [RFC1108] (historic but
                                               in use)

The "padding" you describe is either a No Operation or (per RFC 791):

  Padding:  variable

    The internet header padding is used to ensure that the internet
    header ends on a 32 bit boundary.  The padding is zero.

And that padding is IMMUTABLE, therefore it must be included in the ICV.
Besides, even if it was mutable, it's all zeroes anyway.

Dan

---

From: "R&C Finn" <[email-masked]>
Date: Wed, 11 Apr 2007 21:54:27 -0500

>From previous experience in this area, there should be some nomenclature 
indicating that all bytes that will be used by the ICV calculation procedure 
bet set to known or default values including any padding bytes.