Re: ESP payload type

[Stephen Kent <kent@bbn.com>]

Gina,

>	In RFC 1829, the payload format in section 2 calls for a one
>octet payload type. Will this field have the same value regardless of
>whether the original packet has been compressed? If so, how can one
>determine if the encrypted packet has been compressed. If not, what are
>the values for the payload type for compressed and uncompressed packets?

First, the newly approved IPsec documents are the relevant ones, not 1829.
If compression has been negotiated and employed for an SA, then the
appropriate protocol ID for IPCOMP will appear as the NEXT field in ESP,
indicating that the next level of demuxing and processing is IPCOMP, vs.
TCP, IP, etc.

Steve

P.S.  The encrypted packet would not have been compressed; the plaintext
would have been compressed and the result encrypted.

---

References:

• ESP payload type
• From: gmd@openroute.com (Gina DePlanche)

---

• Prev by Date: Re: I-D ACTION:draft-shima-ipsec-isakmp-cke-type-00.txt
• Next by Date: I-D ACTION:draft-ietf-ipsec-gkmframework-00.txt
• Prev by thread: ESP payload type
• Next by thread: 2nd IEEE Workshop on Mobile Computing Systems and Applications (WMCSA'99)
• Index(es):
  • Main
  • Thread