Re: GSE

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   On Sat, 22 Feb 2003, Francis Dupont wrote:
   
   > => two-space systems are still raisonable long term solutions, especially
   > HIP (Host Identity Payload Protocol) which doesn't share the security
   > concern on the binding between the locator and the identity.
   > (PS: and its overhead is not a problem for guys like me who'd like
   > to hide everything behind ESP :-).
   
   Is there a good write-up of HIP yet?
   
=> draft-jokela-hip-packets-xx.txt and old I-Ds by Robert Moskowitz.

   We should really watch the overhead, because most of the time it's
   simply unnecessary. Want do do voice over IP with IPsec? If you don't do
   the IPsec in the phone, you MUST use tunnel mode as per the RFC.

=> HIP is end-to-end.

   But you can't do routing over IPsec tunnels, so you need another
   GRE tunnel.

=> fortunately this is not 100% true.

   Then comes the ESP overhead, which is actually fairly small but they
   chose to inlcude padding, which IMO was a mistake. Also, the
   initialization vectors eat up a fair number of bytes, while it wouldn't
   be very hard to come up with a scheme where the IV isn't carried inside
   the packet.

=> both are properties of the algorithm(s), not of ESP itself.
And security has a price...

   Then of course we encapsulate all of this in an ethernet
   frame which wastes 64 bits on a preamble and 160 bits on an inter frame
   gap, which are necessary to make the manchester encoding work. Since we
   typically use ethernet with encodings that regulate this stuff at even
   lower layers, most of these 20 bytes are wasted for no reason.
   
   So in order to carry a 64 kbps voice stream in more or less 64 kbps and
   have a reasonable delay, we need to compress the actual payload by a
   factor 4 to make room for the overhead, which is then 78%. About half of
   this could be removed without any impact to functionality.
   
=> if they could be removed they could be compressed too.

   The problem with many headers is that they implement too much. Ideally,
   each function would have its own header so you only need to include the
   headers you're actually going to use. (IPv6 options have the right
   idea.) But of course that leads to header recognition overhead, where
   each header needs a header...
   
=> I am afraid we are outside the scope of the MULTI6 list.

Regards

Francis.Dupont@enst-bretagne.fr