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

RE: Byte-count lifetime enforcement?

I have even more questions about this issue.
It seems reasonable for the receiving end of an SA to count protected
bytes received and, if that number passed the limit, drop the current
packet and start re-keying. (Or implement a soft limit and re-key a bit
earlier). However, should the transmitting side also count protected
bytes? If I am a gateway, wouldn't it be my job not to send more than
the max kbytes? If I do this, the receiving side will never go over the
limit (which I think is good) but it will still have to check to see if
I made a mistake. If both sides implement a soft limit, hopefully one
will be less than the other and re-keying will not start up on both
sides at the same time (at least not too often).
So now I've talked myself into checking both the receive and the xmit
end of my SAs. 

A comment on Dan's statement about having only one SA up. This shouldn't
happen because both are renegotiated at the same time. In any case,
doesn't the original negotiation use the same kbyte limit for both SA's?
Perhaps this is only in my implementation..?

-CJ

	-----Original Message-----
	From:	Dan McDonald [SMTP:danmcd@Eng.Sun.Com]
	Sent:	Friday, June 26, 1998 6:47 PM
	To:	ipsec@tis.com
	Subject:	Byte-count lifetime enforcement?

	As I was chasing bugs in lifetime counts, particularly that my
_outbound_
	number of bytes wasn't consistent with the _inbound_ number of
bytes, the
	thought occurred to me that, while I am self-consistent (after
fixing said
	bug, of course), I might not be consistent with others.

	This _may_ be an interoperability issue in that one side's
byte-count will
	expire before the other side's, leaving one side using an SA
that is expired
	on the other side.  If I'm missing something here (an ISAKMP
Notification of
	some kind?), please let me know.  If I'm not missing anything,
read on for
	more details.

	...

	The Architecture document touches upon this issue with the
following text:

	                   (a) If byte count is used, then the
implementation
	                       SHOULD count the number of bytes to which
the IPsec
	                       algorithm is applied.

	But for ESP, _WHICH_ algororithm?  The number of bytes applied
with
	encryption will be different than authentication.

	We have several options for "number of bytes" counts:

	   * Number of bytes in the "protected" portion of the datagram,
before any
	     security is applied.  This means the transport payload
length or the
	     inner datagram total length.

	   * Number of bytes that get crunched through the _primary_
algorithm.
	     For ESP, this is encryption (and null encryption counts
here), and for
	     AH, it would be authentication.  This would include pad
bytes, etc.

	   * Some other method of byte count, TBD.

	Any "accepted" method?  It's nice to be consistent with your
implementation,
	but we ARE in the interoperability business; it would be nice to
be
	consistent with others too.

	Dan