[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject

NAA25784 for ipsec@tis.com; Tue, 29 Jul 1997 13:56:41 -0700 (PDT)
Date: Tue, 29 Jul 1997 13:56:41 -0700 (PDT)
Message-Id: <199707292056.NAA25784@snow.NSD.3Com.COM>
To: ipsec@tis.com
Subject: payload length change suggestion
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk


According to the July AH draft, due to backward compatibility,
one must subtract 2 from the actual payload length and put
the resulting value in the "payload length" field.

I find the resulting value misleading since the field is
called "payload length" but we're putting there an inaccurate
payload length value.

May I suggest that we calculate the correct payload length
field (e.g. subtract 3) and turn a bit (or some bits) of the 
RESERVED field into a VERSION field to indicate which version 
of AH one is running? 

The current value in the RESERVED field is 0. 0 could
be used to imply that the old AH version was version 0.

I realize that with this suggestion, there'll still be a
backward compatibility problem. For example, 

	A_oldAH <------- B_newAH
		   pkts

given box A running the old AH and box B running the new 
AH, box A will drop AH pkts coming from box B because the 
pkts' reserved field is non-zero.

However, even with the current draft proposal, there's a 
backward compatibility problem. If box A receives a pkt 
from box B, box A will think the authentication data starts 
at an offset which actually contains the sequence number 
field. So box A will still end up dropping the pkts.

Since neither the current draft proposal nor my proposal
offers a perfect backward compatibility solution, we may as 
well calculate an accurate payload length. Otherwise, may be 
we should rename the payload length field to another name.

- Ly