Is there any order?
K SrinivasRao <srinu@trinc.com> Wed, 18 March 1998 19:09 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06145 for ipsec-outgoing; Wed, 18 Mar 1998 14:09:19 -0500 (EST)
Message-Id: <3.0.1.32.19980318170717.006ab134@192.9.200.10>
X-Sender: srinu@192.9.200.10
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Wed, 18 Mar 1998 17:07:17 +0500
To: ipsec@tis.com
From: K SrinivasRao <srinu@trinc.com>
Subject: Is there any order?
Cc: kent@bbn.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Hi folks, Sorry for sending again. I have done mistake regarding subject is concern. With respect to the draft-ietf-ipsec-esp-v2-04.txt 2.4 Padding (for Encryption) Several factors require or motivate use of the Padding field. (case 1) o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. srinu>> Will the encryption algorithm which needs multiple of block size adds the padding that also ensures that the resulting ciphertext terminates on a 4-byte boundary. i.e the requirement of following paragraph(case2). (case2) o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. (case3) o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. srinu>> Is there any ordering of above three cases regarding how to process the packet. Like first apply the packet to process under do case2 and then case1 and then case3. Srinu>> If we are applying more than one cases, is it sure that pad length will not exceed 255 bytes. The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. The padding computation applies to the plaintext portion of the Payload Data, exclusive of the IV (if present). Thank U Bridging the gap between hardware and software with best wishes - K. SrinivasRao(email : srinu@trinc.com )
- Is there any order? K SrinivasRao