[rohc] Re: (in)security of ESP with header compression

[Stephen Kent <kent@bbn.com>]

David,

The ESP processing order at the receiver is authenticate then 
decrypt, IF there are separate authentication and encryption 
algorithms employed, i.e., the common case today. The structure of 
the payload requires this, since the integrity check is applied to 
the ciphertext, not the plaintext, by the sender.

That says that the transmitter processing order is:
	- map to SA (the outbound access control check)
	- compress if appropriate
	- encrypt
	- integrity check


At the receiver the processing is defined as:
	- map to SA using SPI ( a demuxing operation, not a security check)
	- validate sequence number
	- integrity check
	- decrypt
	- decompress if appropriate
	- check against selectors (the inbound access control check)


Sorry for any confusion re my previous response in not spelling out 
all the steps and why they are performed in the order indicated.

Given this ordering of processing steps, it would seem that the main 
issue for a stateful compression algorithm like ROHC is to be smart 
about reacting to out of order arrival, a fact of life if it is to be 
used in the IPsec context.

Steve
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc