RE: [Ipsec] Layer 2 processing inside IPsec

[Francois.PAUL@fr.thalesgroup.com]

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.
  - If a layer 2 processing such as ROHC is tunneled (directly or not) over
IP, one must be careful regarding packet re-ordering. This kind of problem
is dealt with by other layer 2 tunneling frameworks, such as L2TP. Just take
a look at Appendix C of the present L2PTv3 draft
(http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-base-11.txt),
which pinpoints this issue more accurately than RFC 2661. I agree this
problem is not easy to tackle, especially when one wants to determine the
"very short period" after which a missing sequence number is considered lost
rather than misordered ...

F. Paul


-----Message d'origine-----
De : Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
Envoye : lundi 28 juin 2004 22:50
A : sommerfeld@east.sun.com
Cc : Francois.PAUL@fr.thalesgroup.com; ipsec@ietf.org
Objet : Re: [Ipsec] Layer 2 processing inside IPsec 


 In your previous mail you wrote:

   > I disagree: IPsec does not change the order 
   
   That's not at all clear to me.  
   
=> this is misunderstanding: IPsec itself doesn't change the order,
IP can change it and is run under IPsec.

   you cannot naively use ROHC over IPsec.

=> I agree. BTW I am not interested by ROHC itself but by any
compression which can work with IPsec. In fact I believe it still
has to be designed/specified.
   
   An integrated IPsec - ROHC implementation could look at the IPsec
   sequence number and insert its own reorder buffer, but such an
   integration would not be as simple as defining an IP protocol number
   for ROHC.
   
=> nothing can be simple with ROHC (:-). IMHO we talk about ROHC
just because it is the more sophisticated compression...

   It's an architectural issue.  An integrated IPsec-ROHC means that the
   ROHC would have to be inserted into the *middle* of IPsec processing,
   between the policy enforcement part and the encryption part.  
   
=> it seems we agree: something can be done but needs real work.

Thanks

Francis.Dupont@enst-bretagne.fr

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