Re: Your questions

Stephen Kent <kent@bbn.com> Wed, 21 January 1998 15:54 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24063 for ipsec-outgoing; Wed, 21 Jan 1998 10:54:19 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03110705b0ebc8a4ef31@[128.89.0.110]>
In-Reply-To: <3.0.1.32.19980119190024.006946a0@192.9.200.10>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 21 Jan 1998 11:06:10 -0500
To: "srinivasrao.kulkarni" <srinu@trinc.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Your questions
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk


>As far as I know, if any header contains a variable length of data then it
>will have a field for the length of that variable field. But, I found that
>in case of ESP header there is no field that gives the payload length and
>authdata length whereas in AH header it has payload len. From the payload
>length, the authdata length can be determined easily. Is it that the length
>field is missing in ESP header format or is it not part of the header?
>
>And one more thing is that pad length is given for the padding field which
>is also of variable length. Assuming that the datagram has been read into a
>buffer, how can we access the ESP trailer in it since the authentication
>data which succeeds the ESP trailer and the payload data and padding which
>precede the trailer are both variable length fields?

There is no need for an ESP header length field. ESP encapsulates its
payload, so the length of the encapsulated payload, including the ESP
header and trailer, can be determined from the IP total packet length
field, minus the IP header length, the same way one would determine the
size of a TCP or UDP payload.  The ESP header is fixed length, 8 bytes. If
auth data is present, it is fixed length for a specific SA, because the
auth data length is determined by the algorithm that is negotiated for the
SA, e.g., 12 bytes for the default algorithm.  After removing the auth data
(if present), one decrypts the ESP payload and removes the Next header
field.  Then one can work backwards from the pad length field to get to the
real end of the ULP or tunneled IP packet.

>It was said w.r.t draft-ietf-ipsec-auth-hmac-sha196-01.txt Nov 1997
>
>HMAC-SHA-1-96 produces a 160-bit authenticator value.  This 160-bit
>value can be truncated as described in RFC2104.  For use with either
>ESP or AH, a truncated value using the first 96 bits MUST be
>supported.  Upon sending, the truncated value is stored within the
>authenticator field.  Upon receipt, the entire 160-bit value is
>computed and the first 96 bits are compared to the value stored in
>the authenticator field.  No other authenticator value lengths are
>supported by HMAC-SHA-1-96.
>
>My question is how does the receiver know whether the authdata is truncated
>or not i.e is it 96-bit or 160-bit without specifying the length in the ESP
>header ?

Again, the length of the auth data is specified during SA establishment and
then is constant for all traffic on the SA.  Truncated and non-truncated
versions of the same (keyed) hash are assigned different algorithm IDs and
thus are distinguishable at the time of SA establishment.

Steve