Re: AES-CBC draft: Tunnel mode, TTL field of inner header

[Sheila Frankel <sheila.frankel@nist.gov>]

Dear Peter,

Thank you very much for your comment and your detailed reading of the 
draft. However, I believe that the test cases' TTLs in the draft are correct.

In section 5.1.2.1, RFC 2401 says that the encapsulator decrements the TTL 
prior to forwarding. However, there is a caveat mentioned in Note 2: 
"Packets originating from the same node as the encapsulator do not have 
their TTL's decremented, as the sending node is originating the packet 
rather than forwarding it." This is the case in Test cases 7 & 8, since the 
source address in both the tunnel header and the inner header is the same.

Sheila
sheila.frankel@nist.gov

At 02:24 AM 7/15/02, peter.mathes@gmx.de wrote:
>Dear all,
>I just came across one point in the Internet Draft "The AES Cipher Algorithm
>and Its Use With IPsec", <draft-ietf-ipsec-ciph-aes-cbc-04.txt>, June 2002
>that made me wonder. In the last two test vectors (7&8) provided with the
>draft ESP packets in tunnel mode are encryted with AES-CBC. Although RFC 2401
>specifies in (5.1.2) to decrement the TTL field of the inner header this 
>is not
>done in the two mentioned test cases:
>
>----------------
>Case #7:
>
>Original packet:
>IP header (20 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8
>                                         ^^
>.
>.
>.
>
>Pre-encryption Data with original IP header, padding, pad length and
>next header (96 bytes):
>45000054 09040000 4001f988 c0a87b03 ...
>                   ^^
>
>------------------
>
>And also the ciphertext is based on the plaintext with TTL = 40.
>
>
>Mistake? Changes in the specification?
>
>
>Thanks,
>Peter Mathes
>
>
>--
>GMX - Die Kommunikationsplattform im Internet.
>http://www.gmx.net