Subject: Re: [Ipsec] Layer 2 processing inside IPsec

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

In your previous mail you wrote:

   >    Does any one know if such a mechanism was proposed ?
   >
   > => look at draft-vilhuber-hco{ip,esp}-xx.txt
   
   I bet these have long since expired, but I'd be happy to resubmit them
   (as individual submissions). When I first submitted these, there flood
   of responses and comments was astounding. I got one single email about
   it all (saying essentially "Cool.. I like it and have been thinking
   along similar lines"; I think that might even have been you, francis :).
   
=> I remember to have sent such comment (:-)!

   Is the IETF now interested in this thing? Previously, comments (in
   other working groups and other documents) were basically "Why would we
   want to do this?" (which to me seems obvious, of course).
   
=> from MOBIKE charter (goal lists):

(5) Reduction of header overhead involved with mobility-related
  tunnels. This is a performance requirement in wireless
  environments.

So now there is a place for your work!
   
   > Can we continue offline?

=> this was for Francois (I expected he was French :-)
   
   I'm game if you want to include me on a private exchange. I still have
   the drafts, and we can use them as a start, if you like.
   
=> IMHO you should resubmit then before the dead-line!
   
Thanks

[email-masked]

PS: BTW we have a whole team of compression (mainly ROHC as it is
what 3GPP wants) experts. The only missing people are the people who
are interested to buy the idea: at the moment we are at least three
who'd like to sell it (:-)...

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

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 28 Jun 2004 15:16:46 -0700 (PDT)

> => I remember to have sent such comment (:-)!

I remembered correctly then :)

> So now there is a place for your work!

Maybe. I don't really see this as limited to mobility, though. As long
as it's in a mobility-unrelated (i.e. generic) fashion, then I don't
mind doing it there.

The scenarios I've heard so far include stuff like: Customer wants to
replace a voice T1 with a data-T1 and use Voip instead of telco
lines. But with IPsec, the number of calls he can carry on said T1 is
smaller with Voip than with telco stuff, so ipsec+voip so far is not
an option.

If we negate the packet expansion of ipsec via header compression (of
whatever flavor suits them best, I don't really have any religion on
the matter), then the number of calls under ipsec+voip can exceed the
number of calls under 'telco'.

Did that 'compressed' explanation of the scenario make sense?

> => this was for Francois (I expected he was French :-)

I can read french in a limited fashion. I can even understand it, if
you talk reasonably slowly.

Or so I think :)

> => IMHO you should resubmit then before the dead-line!

Well I won't be going to the IETF, so it matters little to me :) But
I'll gladly send them to the submission-thing again (as individual
submissions). If you want to be co-editor and present them in San
Diego, I'd welcome that.

jan

 --
Jan Vilhuber                                            [email-masked]
Cisco Systems, San Jose                                     (408) 527-0847

---

From: Lars Völker <[email-masked]>
Date: Tue, 29 Jun 2004 10:43:32 +0200

Hi!

> Maybe. I don't really see this as limited to mobility, though. As
> long as it's in a mobility-unrelated (i.e. generic) fashion, then
> I don't mind doing it there.

> If we negate the packet expansion of ipsec via header compression
> (of whatever flavor suits them best, I don't really have any
> religion on the matter), then the number of calls under ipsec+voip
> can exceed the number of calls under 'telco'.

The problem with a generic fashion is that only specific protocol
combinations reach a good compression level. It would be very nice to
compress each packet so much that compression would outweigh the size of the
ESP header. This would solve the fragmentation problem in almost every case.
:) But let's check the math:

When using transport mode (--> tunnel mode and compress IP Header to 0) an
ESP header is adding 22-25 Octets (4+4+0..3+2+12).

Let's just say we have UDP selectors anyway and SAVE the whole 8 Octets of
the UDP header. Or we have TCP and could SAVE the whole 20 Octets (does not
seem very reasonable to me)!? Still, this is not enough. :(

If the IP header (IPv6 over ESP over IPv4) could be compressed more Octets
would be found but this is surely not a generic scenario. So this leaves us
to compress an application level protocol as RTP. Are there other
application level protocols for which header compression would work that
well? If not, we still have an overhead by adding ESP.

Don't misunderstand me: I really think the idea to include header for
headers encapsulated by ESP is a good idea but is this saving enough for any
scenario besides mobility? And is it worth it?

Lars

P.S. We could reduce overhead of authentication but IMHO I think we need
authentication at all costs. Only the sequence number field of ESP could
give us a few more octets by compressing it.