> >>
> >> When esn is used then high-order 32 bits are included in ICV
> >> calculation however are not transmitted. Update packet length
> >> to be consistent with auth data offset and length before crypto
> >> operation. High-order 32 bits of esn will be removed from packet
> >> length in crypto post processing.
> >
> > Hi Lukasz,
> > Why you want to do it?
> > I deliberately didn't include SQH bits into the pkt_len/data_len,
> > because it is a temporary data and we are going to drop it anyway.
> > Konstantin
> >
> > Hi Konstantin,
> > Our OcteonTx crypto driver validates pkt_len with auth data length/offset 
> > and it complains
> > because it is told to authenticate more data that a packet holds (according 
> > to pkt_len).
> > I came across this when running IPSec tests which use esn.
> > I understand that sqh 32 bits are temporary and included only for ICV 
> > calculation however
> > not including them in pkt_len for crypto processing is inconsistent in my 
> > opinion.
> > Thanks,
> > Lukasz
> >
> 
> Hi Konstantin,
> 
> I should have elaborated more. When 32 high bits of esn are not included in
> packet length then auth offset and data point to data which is outside packet
> (according to packet length).
> This makes crypto request (auth data length and offset) incoherent with a 
> packet
> which the crypto request points to.
> 
> This is my argument for including 32 high bits of esn into packet length even
> though the inclusion is only temporary.

I understood the reasoning.
Will try to have a closer look in next few days.
Thanks
Konstantin 

Reply via email to