Subject: [rohc] Notes from the HCoIPsec Side-Session at IETF (03/20/06)

From: "Ertekin Emre" <[email-masked]>
Date: Fri, 31 Mar 2006 09:45:45 -0500

All,

Please find below my draft notes from the HCoIPsec side-session last
week at the IETF.  

Participants -- please let me know if I missed anything.

Best Regards,
Emre

------------------------------------------------------------------------
-------------------

Participants
------------
1.  Stephen Kent ([email-masked])
2.  Carsten Bormann ([email-masked])
3.  Yaron Sheffer ([email-masked])
4.  Emre Ertekin ([email-masked])
5.  Christos Christou ([email-masked])
6.  Victor Chao ([email-masked])

Highlights from the HCoIPsec side-session:

The two alternatives to achieving HCoIPsec were reviewed
(draft-jasani-rohc-hcoipsec-alternatives-00.txt).  
 
1) Discussion on the use of the "uncompressed" profile: Considering that
HC algorithms already compress packet headers between 1-3 bytes, it is
desirable to eliminate the additional overhead added with the
"uncompressed" profile.  This makes alternative 1 less attractive.
 
2) Resolution of the HCoIPsec alternatives: There was consensus that the
only difference between the two approaches is the way to identify
uncompressed packets.  The first approach uses the "uncompressed
profile" as the demultiplexing point, and the second approach uses the
"next header" field.  Since the second approach provides a greater
reduction in overhead, HCoIPsec efforts will proceed with the second
approach, as detailed in the alternatives draft.  IANA will be requested
to allocate one value from the next header field for "compressed
headers".
 
3) The ESP sequence number may be used within the decompression module
for detection of mis-ordered packets.
 
4) HCoIPsec does not need to integrity-check a packet after
decompression.  The process will be to integrity-check packet, then
decompress.
 
5) Discussion on the mechanisms needed to achieve feedback from the
decompressor to the compressor.  IKE generally negotiates the pair of
unidirectional SAs between the IPsec gateways.  Therefore, HC context
space will be specific to these two SAs, rather than 1 SA as detailed in
the HCoIPsec I-D.  How a compressor/decompressor/encryptor/decryptor
associates a feedback SA to an HC-enabled SA is an implementation
detail.
 
6) The HCoIPsec draft will be restructured such that it does not read
like a work proposal.  Future revisions of the draft will take the
flavor of a framework document.
 
7) The following documents that are required to achieve HCoIPsec:
   a.  HCoIPsec Framework
   b.  Definition of a new next header field value (IANA allocation)
that indicates "compressed headers"
   c.  IKE/IPsec extensions for HC-session Parameter Negotiation

8) Discussion on unifying header compression algorithms: Perhaps define
a new ROHC Profile, which will enable IPHC/(e)CRTP to be plugged into
ROHC framework.  This way, only one value needs to be allocated from
IANA.  

9) HCoIPsec efforts may be extended to support IPsec Transport Mode
(though this is secondary, and will be considered after the
specification of HCoIPsec for tunnel mode is complete).

10) The HCoIPsec framework is currently a chartered item within the ROHC
WG.  The WGs where the next header field value, IKE/IPsec extensions to
support HCoIPsec, and the unification of HC algorithms I-Ds will be
worked is to be determined.  All of these drafts, however, will be
coordinated between the AVT, ROHC, and possibly the MOBIKE WGs.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc