RE: [Ipsec] Layer 2 processing inside IPsec

[Lars Völker <ipsec-mail@larsvoelker.de>]

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.



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