RE: ipsec error protocol

>RE: ipsec error protocolFrom: owner-ipsec@lists.tislabs.com on behalf of Stephen Kent [kent@bbn.com]
>Sent: Thursday, February 01, 2001 6:40 AM
>To: sankar ramamoorthi
>Cc: ipsec@lists.tislabs.com
>Subject: RE: ipsec error protocol
>
>Sankar,
>
>
> >RE: ipsec error protocolFrom: Stephen Kent [kent@bbn.com]
> >Sent: Wednesday, January 31, 2001 2:59 PM
> >To: sankar ramamoorthi
> >Cc: ipsec@lists.tislabs.com
> >Subject: RE: ipsec error protocol
> >
> >Sankar,
> >
> >
> > <snip>
> >
> > This is where I was getting confused. How are sequence numbers maintained
> > on the outbound side?
> >
> >as full 64-bit values
> >
> >
> > Is it maintained as a continously incresing 64bit counter? If so
> > since the upper 32 bits are not sent over the wire, a replayed packet and a
> > genuine packet whose lower 32 bit has rolled over may look the same to
> > the receiver of the packet - right?
> >
> >
> >it would look the same until the integrity check was performed.
> >
> >
> >admittedly, this scheme places a limit on receiver window size, i.e., it must be less than 2**32.
> >
> >
> >anyone have a problem with that?
> >
>
>
> If the receiver window is limited to 2**32 bits, then it means
> at 10Gig/sec speeds the receiver has to rekey after 400 seconds.
>
> Is that acceptable?
>
>
>me thinks you're not reading the words I write! The receiver window does not determine rekey times; it determines how late (in packet delivery order) a packet can arrive at a receiver and still be accepted (vs. being rejected as a replay even when it is not a relay).
>
Agreed - I was not reading the words properly. It was due to my jumping to
the conclusion that the upper bound of the receiver window has to
be 2**32. That conclusion came from my misunderstanding that only 32 bits of
the sequence number space is included in the checksum calculation.