%% You should probably cite draft-ietf-ipsecme-diet-esp instead of this I-D.
@techreport{mglt-ipsecme-diet-esp-07,
    number =    {draft-mglt-ipsecme-diet-esp-07},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/07/},
    author =    {Daniel Migault and Tobias Guggemos and Carsten Bormann and David Schinazi},
    title =     {{ESP Header Compression and Diet-ESP}},
    pagetotal = 47,
    year =      2019,
    month =     mar,
    day =       11,
    abstract =  {With the use of encrypted ESP for secure IP communication, the compression of IP payload is only possible with complex frameworks, such as RObust Header Compression (ROHC). Such frameworks are too complex for numerous use cases and especially for IoT scenarios, which makes IPsec not being used here, although it offers architectural benefits. ESP Header Compression (EHC) defines a flexible framework to compress communications protected with IPsec/ESP. Compression and decompression is defined by EHC Rules orchestrated by EHC Strategies. The necessary state is hold within the IPsec Security Association and can be negotiated during key agreement, e.g. with IKEv2. The document specifies the necessary parameters of the EHC Context to allow compression of ESP and the most common included protocols, such as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules. It also defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent over a single TCP or UDP session.},
}