[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0

Henry Spencer wrote:
> 
> On Mon, 13 Aug 2001, William Dixon wrote:
> > If the keying protocol wishes to use UDP-ESP, and multiplex that
> > encapsulation on it's own port, then the keying protocol MUST provide at
> > least a 4byte 0x00 flag which will share the same position of the
> > UDP-ESP SPI.  Thus a non-zero SPI means data.  A zero SPI means control.
> 
> Before attempting to solve this problem, it seems to me that one should
> first ask whether it is worth solving.

This is good advice and should be applied to these questions at least:
a) Do we really want to make this draft a generic draft, usable by several
   key management protocols? Or do we want to keep it simple, understandable
   and IKE-specific? If some other key management protocol needs it, why
   should this draft / this WG solve the problem? (In particular, KINK would
   probably be better off writing their own simple document on the matter.)
b) What is the actual NEED to save bits on the wire? What are the things we
   can tinker with to save them? I.e.
   - We can have separate channels for IKE and ESPUDP, which saves 8 bytes 
     per ESPUDP packet. Then we need NAT-keepalives for both channels. Do these
     extra keepalives cause more traffic than is saved? I'm not so sure.
   - If we can change IKE header field order and steal one bit of ESP SPI
     field, we can also save the 8 bytes per packet, but this is not very 
     practical. (ISAKMP flags field first, cookies starting at byte 5. This
     might be usable for KINK?)

It's also good to remember that UDP header also takes 8 bytes. And 8 bytes of
UDP header followed by 8 bytes of zero should compress pretty well at some
header compression algorithm. And the checksum is also zero.

So, I would prefer not to change this draft if it's not really necessary.
There was quite a lot of discussion about these things among the authors, but
if this WG wants otherwise, I can of course modify the draft.

Yes, I agree completely with the AH-removal choice.

Ari

-- 
Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com 

F(ully)-Secure products: Securing the Mobile Enterprise
References: