1. 1 Header Compression over IPsec (HCoIPsec) Emre Ertekin, Christos Christou, Rohan Jasani { ertekin_emre@bah.com, christou_chris@bah.com, jasani_rohan@bah.com }ertekin_emre@bah.comchristou_chris@bah.comjasani_rohan@bah.com Booz Allen Hamilton

2. 2 Outline HCoIPsec Update IKEv2 Extensions IANA Protocol Number Allocation Non-unification vs. Unification

3. 3 HCoIPsec Draft (-02) Resolved a number of outstanding issues with the previous version of the HCoIPsec I-D at the 65 th IETF Meeting in March 2006 –Consensus reached for HCoIPsec Alternative #2, described in (draft-jasani-hcoipsec- alternatives-00.txt) (-02) version reflects these discussions –In addition, rather than a “work proposal” flavor, the current draft now details the “framework” for integrating HC with IPsec Major changes include the following –Addition of inbound/outbound HCoIPsec processing, as documented in Alternative #2 Clarifies both inbound and outbound packet processing at an IPsec implementation –Eliminated the “Example Operation” section, as detailed in the previous drafts –Use of the Next Header field to demultiplex compressed versus uncompressed packets received on an HC-enabled SA –Documented that bi-directional communications between decompressor and compressor is an implementation issue –Indicated that future work may extend the HCoIPsec framework for transport mode SAs

4. 4 Summary of HCoIPsec Alternative #2 Benefits –Only need to have one SA instantiated to carry compressed and uncompressed traffic Could be useful in environments (6lowpan) where resources are limited –No HC overhead is incurred for uncompressed traffic via the “uncompressed profile”; Protocol Number registry (i.e., security protocol “next header” field) is used to identify uncompressed traffic Considerations –Requires the reservation of a Next Header field value from IANA

5. 5 Documents Needed Extensions required to traditional HC schemes to tolerate increased reordering and packet loss between compressor and decompressor ROHCv2-based profiles and eCRTP are candidate compression schemes for HCoIPsec  Document (A): Initialization and negotiation of HC-specific parameters and IPsec processing description  *Extensions to IKEv2/IPsec to support HC parameter configuration  Document (B): Allocation of one value for “compressed headers” from the IANA “Protocol Numbers” registry  *Allocation requests one protocol number for “RObust Header Compression” * The specifics of these drafts depends on if the IPHC/cRTP/eCRTP line of HC algorithms are specified as a profile under the ROHC framework (i.e., HC algorithms are unified)

6. 6 Document (A): HC Parameter Configuration HC schemes require several parameters to be negotiated prior to operation –Traditionally handled by an underlying link layer protocol (i.e., PPP) For HCoIPsec, IKE will be extended to provide this negotiation –IKE is used to establish SAs, conduct parameter negotiations and exchange keying material Extensions will focus on adding support to IKEv2 as opposed to IKEv1

7. 7 Document (A): IKEv2 Extensions to Support HC Parameter Configuration To support HC parameter configuration, the “Security Association” payload of the “CREATE_CHILD_SA” exchange will need to be extended List of allowable SA payload transform types must be augmented to support HC scheme negotiation –A new transform type, “HC Scheme” and its associated values need to be defined to enable HC operation on a particular SA List of allowable SA payload transform attributes must be augmented to support HC channel parameters –HC parameters specific to a particular HC scheme need to be added as attributes for each HC scheme Further details about the IKEv2 extensions are dependent on unification of the HC algorithms

8. 8 Document (B): Allocation of IANA Next Header Field Allocation of one value needed from the IANA “Protocol Numbers” registry to indicate that a packet payload contains compressed headers Instead of making the allocation specific to HCoIPsec, generalize the request, thereby not precluding the allocation’s use in other scenarios –IP Tunnels are also used outside the context of IPsec (e.g., mobility) –HC algorithms can be integrated with other tunneling mechanisms as well, by compressing packets at the ingress of the tunnel, and decompressing at the egress Assuming that the two HC algorithms are unified under the ROHC framework, only one value from IANA would be required –Allocation request for one protocol number for “Robust Header Compression”

9. 9 Decision: Unification of HC Algorithms Identification of compressed packets through the next header field may require multiple values from the IANA “Protocol Numbers” registry –Allocation of a value from the “constrained” registry requires a thorough justification Unification of HC schemes has been proposed to reduce the number of IANA values to a single value for HCoIPsec –Unification would involve defining IPHC and ECRTP as a new ROHC profile –Resulted in a debate between non-unification and unification of HC schemes Additional trades to each approach need to be discussed in order to determine a way forward –The trades for each approach will be detailed in subsequent slides

10. 10 Non-unification Approach HC algorithms are treated as separate entities –No modification is required to either HC algorithms The next header field is used to identify if a packet contains compressed headers –Requires the reservation of at least one new value from IANA for the Next Header field (one value per HC-type will be required) IKEv2 uses the SA field of the CREATE_CHILD_SA exchange to negotiate HC parameters –One new transform type must be added to indicate which HC algorithm is supported by the SA A transform type value is required for each HC algorithm New transform type values must be assigned for new HC algorithms –Multiple transform attributes must be added One new attribute is required for each HC channel parameter for each HC architecture

11. 11 Trades: Non-unification Approach Benefits: –No need to define new ROHC profiles to add support for other HC schemes (e.g., IPHC, cRTP, ECRTP) Considerations: –Requires the reservation of additional IANA Protocol Number values Multiple values may be required, depending on HCoIPsec implementation –IKEv2 needs to be modified each time a new HC scheme or new HC configuration parameter is introduced

12. 12 Unification Approach ROHC and ECRTP/cRTP/IPHC line of HC algorithms are unified with one-another –Definition of a new profile in the ROHC framework which specifies ECRTP/cRTP/IPHC Perhaps RoHC negotiates the ECRTP/cRTP/IPHC scheme channel parameters (e.g., F_MAX_PERIOD, MAX_HEADER) within the new profile (?) May infer ECRTP/cRTP/IPHC scheme channel parameters from its own negotiable parameters, to eliminate redundant fields between HC schemes (?) The next header field is used to identify if a packet contains compressed headers –Requires the reservation of exactly one new value from the IANA for the Next Header field IKE uses SA field of the CREATE_CHILD_SA exchange to negotiate HC parameters –One new transform type is added to indicate if ROHC is supported –One new attribute is required for each negotiable parameter for ROHC (e.g., MRRU, PROFILES) –One new attribute may be required for each negotiable parameter for other HC algorithms (depends on how the HC algorithms are unified)

13. 13 Trades: Unification Approach Benefits: –Requires a single IANA Protocol Number value because all other HC algorithms made available within the ROHC framework –IKEv2 does not need to be modified each time a new non-ROHC channel parameter is introduced Only have to modify the associated ROHC profile –IKEv2 does not need to be modified each time a new HC scheme is introduced; a new RoHC profile will be defined Easier to add a RoHC profile as opposed to modifying IKEv2 Considerations –New RoHC profile must be defined to support other HC architectures A new ROHC profile is required for each additional HC scheme ROHC will negotiate required parameters for other HC algorithms