Subject: [Ipsec] Layer 2 processing inside IPsec

From: [email-masked]
Date: Fri, 25 Jun 2004 19:20:06 +0200

Hello,

I am looking for a simple and efficient way to combine ROHC (Robust header
compression) and IPsec in tunnel mode, in the case of non-NULL ESP
encryption. This may be of high interest in the context of transporting VoIP
flows through encrypted tunnels, for example.

RFC 3095 (ROHC) seems to deal only with these two cases :
  - If non-NULL encryption is used, the profile proposed in section 5.12 of
RFC 3095 is limited to the compression of the ESP/IP header chain.
  - If NULL encryption algorithm is used (i.e : only authentication is
afforded by the SA through ESP), then section 5.8.4.3 describes how the
compressed header chain may be extended to higher level protocols (IP for
tunnel mode, UDP, RTP).

I wonder if the following possibility has already been considered :

In the case of tunnel mode with ESP non-NULL encryption, IPsec applies
encryption to the whole IP packet. So, it is possible to insert ROHC
compression just before ESP encryption.
At the destination IPsec tunnel endpoint, ROHC decompression may be inserted
just after ESP decryption.
In order for this ROHC insertion to map cleanly with the IPsec framework, it
should be considered as a new type of "next header". I looked up in
http://www.iana.org/assignments/protocol-numbers.txt, but I did not find any
number allocated to ROHC in this protocol number space : should it be
possible to apply for one ? Perhaps it should be necessary to extend IKE
child SA parameter values in order for such a tunnel to be negotiated.

When RTP/UDP/IP plain text packets are ROHC-compressed and then
ESP-encrypted, the ROHC profile defined in RFC 3095 sec. 5.8.4.3 (ESP/IP)
may be applied on the outer IP pakcets, on each IP hop of the "unprotected"
IP network.

Does any one know if such a mechanism was proposed ?

F. Paul

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Francis Dupont <[email-masked]>
Date: Sat, 26 Jun 2004 11:08:48 +0200

In your previous mail you wrote:

=> look at draft-vilhuber-hco{ip,esp}-xx.txt
This is also a goal of the MOBIKE WG.
BTW I believe we can do more in the ESP tunnel context than in the
standard one, for instance class more header fields as "static"
and reuse the SPI as a context number...
Can we continue offline?

Thanks

[email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Sun, 27 Jun 2004 20:33:11 -0400

I just skimmed rfc3095 for the first time so I might have missed
something, but I can see a couple potential problems:

 - ROHC requires that the lower layer not reorder packets, whereas
IPsec includes replay protection with a sequence number, it does *not*
put packets back into their original order on receive.

 - ROHC changes the encoding of header fields which are used for
access control purposes by IPsec (inner tunnel headers, payload
protocol, and transport-layer ports); a naive integration of ROHC
inside IPsec would bypass IPsec's post-decryption access controls.

					- Bill

---

From: Lars Völker <[email-masked]>
Date: Mon, 28 Jun 2004 10:33:03 +0200

> put packets back into their original order on receive.
That’s the main problem but if ROHC and IPsec would be just used for the
access link (AFAIK: that’s where it should be used) the problem is rather
small. (Single link, just 1 hop, probably no reordering.)

There should not be a problem to use ROHC first and IPsec after that. Just
set up the SPD in the right way (e.g. Selector=IPs only). Unfortunately ROHC
is not always able to reduce packet size so much that IPsec would not have
to fragment the ROHC packets... depends on your data.

ROHC was designed to be used over cellular links. I don't think that ROHC
would work that well over the internet for the problem with packet
reordering.

Lars

--
Lars Völker
Institute of Telematics, University of Karlsruhe 
Zirkel 2, 76128 Karlsruhe
Phone: +49 721 - 608 6397

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Jun 2004 12:14:58 +0200

=> I disagree: IPsec does not change the order (so it can't have
a negative effect) and more, it helps the detection of reordering
(by something else) and lost (i.e., it can have a positive effect).

=> I believe you refer to RFC 2401 section 5.2.1 steps 2 and 3.
Obviously the decompression must be integrated, i.e., done just after
decryption and before sanity post-decryption checks. BTW the checked
fields are likely not transported in packets but taken from the
decompression context. IMHO this is an implementation issue more
than a real problem.

Thanks

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 28 Jun 2004 08:22:06 -0400

> I disagree: IPsec does not change the order 

That's not at all clear to me.  

> (so it can't have a negative effect) and more, it helps the
> detection of reordering (by something else) and lost (i.e., it can
> have a positive effect).

No, it seems perfectly clear.

IPsec runs over IP, which is allowed to reorder packets.

ROHC runs over link layers which are not allowed to reorder packets.

Unless you have some impossible-to-obtain-in-general out-of-band
knowledge that an IPsec tunnel will only traverse links *and* routers
which never reorder packets, you cannot naively use ROHC over IPsec.

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.

> I believe you refer to RFC 2401 section 5.2.1 steps 2 and 3.

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.  

Again, not so simple as merely defining an IP payload number for ROHC.

						- Bill

---

From: Paul Koning <[email-masked]>
Date: Mon, 28 Jun 2004 11:19:39 -0400

>>>>> "Francis" == Francis Dupont <[email-masked]> writes:

 Francis> In your previous mail you wrote: 

 >>I just skimmed rfc3095 for
 >> the first time so I might have missed something, but I can
 >> see a couple potential problems:
   
 >> - ROHC requires that the lower layer not reorder packets,
 >> whereas IPsec includes replay protection with a sequence
 >> number, it does *not* put packets back into their original
 >> order on receive.
   
 Francis> => I disagree: IPsec does not change the order (so it can't
 Francis> have a negative effect) and more, it helps the detection of
 Francis> reordering (by something else) and lost (i.e., it can have a
 Francis> positive effect).

Not true.

A typical IPsec implementation probably doesn't reorder things, but
since it's a datagram service it would be allowed to do so.

And IPsec does NOT detect reordering.  It detects replay (repeated
packets).  The typical "replay window" implementation will -- as a
side effect -- reject reordering by an amount larger than the reply
window, but that's just an artifact of the implementation, it's not
the goal of that mechanism.

The real point is that IP networks will reorder packets, as they are
allowed to, and IPsec will not stand in the way.  So if someone
expects an IPsec-protected communication scheme to offer ordered
delivery, they may get an unpleasant surprise because that's not what
you're offered.

In some cases, deploying IPsec may cause a lot of reordering.  For
example, some implementations send fragments in "reverse" order.
That's not a really good idea, but it is perfectly legal.

       paul

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Jun 2004 22:50:15 +0200

=> 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.

=> nothing can be simple with ROHC (:-). IMHO we talk about ROHC
just because it is the more sophisticated compression...

=> it seems we agree: something can be done but needs real work.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Jun 2004 23:20:29 +0200

Not true.
   
=> I already answered to Bill: this is misunderstanding...

   And IPsec does NOT detect reordering.

=> but IPsec uses an anti-replay counter which is always incremented
at each packet in a SA: this counter can be used to detect reordering
between the two ends of the SA.

   It detects replay (repeated
   
=> this is not what I tried to mean.

=> same.

=> no name please (:-). My idea is if someone designs a dedicated
compression for IPsec he could use the anti-replay counter to
at least detect and perhaps support small amount of reordering
or lost. So compression can take benefit of IPsec, when Bill's
message was a bit negative/pessimistic.

Thanks