Header Compression over IPsec (HCoIPsec) <draft-ietf-rohc-hcoipsec-02.txt> - PowerPoint PPT Presentation

About This Presentation
Title:

Header Compression over IPsec (HCoIPsec) <draft-ietf-rohc-hcoipsec-02.txt>

Description:

Title: Header Compression over IPsec (HCoIPsec) Author: Booz Allen Hamilton Last modified by: Booz Allen Hamilton Created Date: 7/27/2005 4:25:54 PM – PowerPoint PPT presentation

Number of Views:66
Avg rating:3.0/5.0
Slides: 14
Provided by: BoozA5
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

Title: Header Compression over IPsec (HCoIPsec) <draft-ietf-rohc-hcoipsec-02.txt>


1
Header Compression over IPsec (HCoIPsec)ltdraft-i
etf-rohc-hcoipsec-02.txtgt
  • Emre Ertekin, Christos Christou, Rohan Jasani
  • ertekin_emre_at_bah.com, christou_chris_at_bah.com,
    jasani_rohan_at_bah.com
  • Booz Allen Hamilton

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

3
HCoIPsec Draft (-02)
  • Resolved a number of outstanding issues with the
    previous version of the HCoIPsec I-D at the 65th
    IETF Meeting in March 2006
  • Consensus reached for HCoIPsec Alternative 2,
    described in (draft-jasani-hcoipsec-alternatives-0
    0.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
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
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
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
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
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 allocations 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
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
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
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
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
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
Write a Comment
User Comments (0)
About PowerShow.com
Home About Us Terms and Conditions Privacy Policy Presentation Removal Request Contact Us
Copyright 2024 CrystalGraphics, Inc. — All rights Reserved. PowerShow.com is a trademark of CrystalGraphics, Inc.
The PowerPoint PPT presentation: "Header Compression over IPsec (HCoIPsec) " is the property of its rightful owner.
Do you have PowerPoint slides to share? If so, share your PPT presentation slides online with PowerShow.com. It's FREE!