RE: [Ipsec] Layer 2 processing inside IPsec

[Francois.PAUL@fr.thalesgroup.com]

This is the reason why it is proposed to insert decompression *between*
decryption and policy enforcement. Once the encrypted payload is decrypted,
if the "next header" field shows that it is a ROHC-compressed packet, the
appropriate decompressor is applied, which produces a regular IPv4 or IPv6
packet header. Then, the classical IPsec access control checks are applied.

This is described in details in Jan Vilhuber's proposal, though the present
draft invokes compression schemes (not so) different from ROHC.

F. Paul

-----Message d'origine-----
De : Stephen Kent [mailto:kent@bbn.com]
Envoye : vendredi 2 juillet 2004 16:15
A : Francois.PAUL@fr.thalesgroup.com
Cc : Francis.Dupont@enst-bretagne.fr; sommerfeld@east.sun.com;
ipsec@ietf.org
Objet : RE: [Ipsec] Layer 2 processing inside IPsec


At 8:10 PM +0200 6/30/04, Francois.PAUL@fr.thalesgroup.com wrote:
>I summarize hereafter the main points that arise from the different
messages
>posted to this list :
>   - Combining ROHC (or whichever generic compression frameworks suits) and
>IPsec in an efficient way leads to an integration of ROHC in the middle of
>IPsec. From the IPsec framework point of view, this could take the form ESP
>used in tunnel mode, but with a specific "next header" value different from
>"IP", in order for the policy enforcement processing to take place just
>after decryption and decompression, along the lines of what Jan Vilhuber
>proposed.

tunnel mode requires that the next header be IP (v4 or v6) because 
that header is used for the access control checks. So I don't 
understand your description above.

Steve

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec