draft-ietf-rohc-hcoipsec-06.txt   draft-ietf-rohc-hcoipsec-07.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft C. Christou
Intended status: Informational R. Jasani Intended status: Informational R. Jasani
Expires: February 28, 2008 J. Pezeshki Expires: July 3, 2008 J. Pezeshki
Booz Allen Hamilton Booz Allen Hamilton
August 27, 2007 December 31, 2007
Integration of Robust Header Compression (RoHC) over IPsec Security Integration of Robust Header Compression (RoHC) over IPsec Security
Associations Associations
draft-ietf-rohc-hcoipsec-06 draft-ietf-rohc-hcoipsec-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 28, 2008. This Internet-Draft will expire on July 3, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
IP Security (IPsec) provides various security services for IP IP Security (IPsec) provides various security services for IP
traffic. However, the benefits of IPsec come at the cost of traffic. However, the benefits of IPsec come at the cost of
increased overhead. This document outlines a framework for increased overhead. This document outlines a framework for
skipping to change at page 2, line 13 skipping to change at page 2, line 13
By compressing the inner headers of IP packets, RoHCoIPsec proposes By compressing the inner headers of IP packets, RoHCoIPsec proposes
to reduce the amount of overhead associated with the transmission of to reduce the amount of overhead associated with the transmission of
traffic over IPsec Security Associations (SAs). traffic over IPsec Security Associations (SAs).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4
5. Overview of the RoHCoIPsec Framework . . . . . . . . . . . 4 5. Overview of the RoHCoIPsec Framework . . . . . . . . . . . 5
5.1. RoHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5 5.1. RoHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5
5.2. Summary of the RoHCoIPsec Framework . . . . . . . . . . . 5 5.2. Summary of the RoHCoIPsec Framework . . . . . . . . . . . 5
6. Details of the RoHCoIPsec Framework . . . . . . . . . . . 6 6. Details of the RoHCoIPsec Framework . . . . . . . . . . . 6
6.1. RoHC and IPsec Integration . . . . . . . . . . . . . . . . 6 6.1. RoHC and IPsec Integration . . . . . . . . . . . . . . . . 6
6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 6.1.1. Header Compression Protocol Considerations . . . . . . . . 8
6.1.2. Initialization and Negotiation of the RoHC Channel . . . . 9 6.1.2. Initialization and Negotiation of the RoHC Channel . . . . 9
6.1.3. Encapsulation and Identification of Header Compressed 6.1.3. Encapsulation and Identification of Header Compressed
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10 6.2. RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10
10. Informative References . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . 14
1. Introduction 1. Introduction
This document outlines a framework for integrating RoHC [ROHC] over This document outlines a framework for integrating RoHC [ROHC] over
IPsec [IPSEC] (RoHCoIPsec). The goal of RoHCoIPsec is to reduce the IPsec [IPSEC] (RoHCoIPsec). The goal of RoHCoIPsec is to reduce the
protocol overhead associated with packets traversing between IPsec SA protocol overhead associated with packets traversing between IPsec SA
endpoints. This can be achieved by compressing the transport layer endpoints. This can be achieved by compressing the transport layer
skipping to change at page 3, line 45 skipping to change at page 3, line 45
The authors target members of both the RoHC and IPsec communities who The authors target members of both the RoHC and IPsec communities who
may consider extending the RoHC and IPsec protocols to meet the may consider extending the RoHC and IPsec protocols to meet the
requirements put forth in this document. In addition, this document requirements put forth in this document. In addition, this document
is directed towards vendors developing IPsec devices that will be is directed towards vendors developing IPsec devices that will be
deployed in bandwidth-constrained IP networks. deployed in bandwidth-constrained IP networks.
3. Terminology 3. Terminology
Terminology specific to RoHCoIPsec is introduced in this section. Terminology specific to RoHCoIPsec is introduced in this section.
Compressed Traffic RoHC Process
Traffic that is processed by a RoHC compressor. Packet headers Generic reference to a RoHC instance (as defined in RFC 3759), or
are compressed using a RoHC profile. any supporting RoHC components.
Uncompressed Traffic Compressed Traffic
Traffic that is not processed by the RoHC compressor. Instead, Traffic that is processed by the ROHC compressor instance. Packet
this type of traffic bypasses the RoHC process. headers are compressed using a specific header compression
protocol.
RoHC Process Uncompressed Traffic
Generic reference to either the ROHC compressor or decompressor. Traffic that is not processed by the ROHC compressor instance.
Instead, this type of traffic bypasses the RoHC process.
IPsec Process IPsec Process
Generic reference to the IPsec process defined in [IPSEC]. Generic reference to the Internet Protocol Security (IPsec)
process.
Next Header Next Header
Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) Refers to the Protocol (IPv4) or Next Header (IPv6, Extension)
field. field.
4. Problem Statement: IPsec Packet Overhead 4. Problem Statement: IPsec Packet Overhead
IPsec mechanisms provide various security services for IP networks. IPsec mechanisms provide various security services for IP networks.
However, the benefits of IPsec come at the cost of increased per- However, the benefits of IPsec come at the cost of increased per-
skipping to change at page 5, line 13 skipping to change at page 5, line 15
5. Overview of the RoHCoIPsec Framework 5. Overview of the RoHCoIPsec Framework
5.1. RoHCoIPsec Assumptions 5.1. RoHCoIPsec Assumptions
The goal of RoHCoIPsec is to provide efficient transport of IP The goal of RoHCoIPsec is to provide efficient transport of IP
packets between IPsec devices, without compromising the security packets between IPsec devices, without compromising the security
services offered by IPsec. As such, the RoHCoIPsec framework has services offered by IPsec. As such, the RoHCoIPsec framework has
been developed based on the following assumptions: been developed based on the following assumptions:
o RoHC will be leveraged to reduce the amount of overhead associated o RoHC will be leveraged to reduce the amount of overhead associated
with packets traversing an IPsec SA with packets traversing an IPsec SA
* Support for legacy HC algorithms (e.g. IPHC, CRTP, ECRTP) over
IPsec may be provided through the specification of new RoHC
profiles (e.g. [ROHC-CRTP])
o RoHC will be instantiated at the IPsec SA endpoints, and will be o RoHC will be instantiated at the IPsec SA endpoints, and will be
applied on a per-SA basis applied on a per-SA basis
o Once the decompression operation completes, decompressed packet
headers will be identical to the original packet headers before
compression
5.2. Summary of the RoHCoIPsec Framework 5.2. Summary of the RoHCoIPsec Framework
RoHC reduces packet overhead in a network by exploiting intra- and RoHC reduces packet overhead in a network by exploiting intra- and
inter-packet redundancies of network and transport-layer header inter-packet redundancies of network and transport-layer header
fields of a flow. fields of a flow.
Current RoHC protocol specifications compress packet headers on a Current RoHC protocol specifications compress packet headers on a
hop-by-hop basis. However, IPsec SAs are instantiated between two hop-by-hop basis. However, IPsec SAs are instantiated between two
IPsec implementations, with multiple hops between the IPsec IPsec implementations, with multiple hops between the IPsec
skipping to change at page 7, line 23 skipping to change at page 7, line 23
+-----+ | +-----+ +---------+ | +-----+ | +-----+ +---------+ |
| | | | | | | |
| | |-------------------------> Path 2 | | |-------------------------> Path 2
| | | (RoHC-enabled SA) | | | (RoHC-enabled SA)
| +-------------------------------+ | +-------------------------------+
| |
| |
| |
| |
+-----------------------------------------> Path 3 +-----------------------------------------> Path 3
(RoHC-disabled SA) (ROHC-disabled SA)
Figure 1: Integration of RoHC with IPsec. Figure 1: Integration of RoHC with IPsec.
The process illustrated in Figure 1 augments the IPsec processing The process illustrated in Figure 1 augments the IPsec processing
model for outbound IP traffic (protected-to-unprotected). Initial model for outbound IP traffic (protected-to-unprotected). Initial
IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1). IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1).
The RoHC data item (part of the SA state information) retrieved from The RoHC data item (part of the SA state information) retrieved from
the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if
the traffic traversing the SA is handed to the RoHC module (Figure 1, the traffic traversing the SA is handed to the RoHC module (Figure 1,
decision block A). Packets selected to a RoHC-disabled SA must decision block A). Packets selected to a RoHC-disabled SA must
follow normal IPsec processing and must not be sent to the RoHC follow normal IPsec processing and must not be sent to the RoHC
module (Figure 1, Path 3). Conversely, packets selected to a RoHC- module (Figure 1, Path 3). Conversely, packets selected to a RoHC-
enabled SA must be sent to the RoHC module. The decision at block B enabled SA must be sent to the RoHC module. The decision at block B
then determines if the packet can be compressed. If it is determined then determines if the packet can be compressed. If it is determined
that the packet will be compressed, the Next Header field of the that the packet will be compressed, an Integrity Algorithm is used to
security protocol header (e.g., ESP, AH) is populated with a "RoHC" compute an Integrity Check Value (ICV) for the uncompressed packet
identifier, and packet headers are compressed (Figure 1, Path 1). ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], Section 2.1). After this, the
However, if it is determined that the packet will not be compressed Next Header field of the security protocol header (e.g., ESP, AH) is
(e.g., due to one the reasons described in Section 6.1.3), the Next populated with a "RoHC" identifier, the packet headers are
Header field is populated with the appropriate value indicating the compressed, and the computed ICV is prepended to the packet, in front
next level protocol (Figure 1, Path 2). After the RoHC process of the compressed header (Figure 1, Path 1). However, if it is
completes, IPsec processing resumes, as described in Section 5.1, determined that the packet will not be compressed (e.g., due to one
Step3a, of [IPSEC] (specifically, "IPsec processing is as previously the reasons described in Section 6.1.3), the Next Header field is
defined..."). populated with the appropriate value indicating the next level
protocol (Figure 1, Path 2). After the RoHC process completes, IPsec
processing resumes, as described in Section 5.1, Step3a, of [IPSEC]
(specifically, "IPsec processing is as previously defined...").
The process illustrated in Figure 1 also augments the IPsec The process illustrated in Figure 1 also augments the IPsec
processing model for inbound IP traffic (unprotected-to-protected). processing model for inbound IP traffic (unprotected-to-protected).
For inbound packets, IPsec processing is performed ([IPSEC], Section For inbound packets, IPsec processing is performed ([IPSEC], Section
5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section
5.2, Step 4) . After AH or ESP processing, the RoHC data item 5.2, Step 4) . After AH or ESP processing, the RoHC data item
retrieved from the SAD entry will indicate if traffic traversing the retrieved from the SAD entry will indicate if traffic traversing the
SA is handed to the RoHC module ([IPSEC], Section 5.2, Step 3a). SA is handed to the RoHC module ([IPSEC], Section 5.2, Step 3a).
Packets traversing an RoHC-disabled SA must follow normal IPsec Packets traversing an RoHC-disabled SA must follow normal IPsec
processing and must not be sent to the RoHC module. Conversely, processing and must not be sent to the RoHC module. Conversely,
packets traversing an RoHC-enabled SA must be sent to the RoHC packets traversing an RoHC-enabled SA must be sent to the RoHC
module. The decision at block B is determined by the value of the module. The decision at block B is determined by the value of the
Next Header field of the security protocol header. If a RoHC header Next Header field of the security protocol header. If a RoHC header
is indicated, decompression is applied (Figure 1, Path 1). However, is indicated, decompression is applied, and the decompressed packet
if the Next Header field does not indicate a RoHC header, the is used with the RoHCoIPsec Integrity Algorithm to compute a value
decompressor must not attempt decompression (Figure 1, Path 2). Once that is compared to the ICV that was calculated at the compressor.
the RoHC module completes processing, IPsec processing resumes, as If this computed value equals the ICV, the packet leaves the RoHC
described in Section 5.2, Step 4 of [IPSEC] (specifically "Then match module (Figure 1, Path 1); otherwise, the packet is dropped. If the
the packet against the inbound selectors identified by the SAD ..."). Next Header field does not indicate a RoHC header, the decompressor
must not attempt decompression (Figure 1, Path 2). Once the RoHC
module completes processing, IPsec processing resumes, as described
in Section 5.2, Step 4 of [IPSEC] (specifically "Then match the
packet against the inbound selectors identified by the SAD ...").
Note that to further reduce the size of an IPsec-protected packet, Note that to further reduce the size of an IPsec-protected packet,
RoHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested RoHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested
fashion. This process is detailed in [IPSEC-ROHC], Section 3.2. fashion. This process is detailed in [IPSEC-ROHC], Section 3.2.
6.1.1. Header Compression Protocol Considerations 6.1.1. Header Compression Protocol Considerations
The initial specification of RoHC [ROHC] may need to be extended to The initial specification of RoHC [ROHC] may need to be extended to
operate efficiently over IPsec SAs. Specifically, compressor and operate efficiently over IPsec SAs. Specifically, compressor and
decompressor implementations must account for increased tolerance to decompressor implementations must account for increased tolerance to
skipping to change at page 8, line 45 skipping to change at page 9, line 4
mechanisms to improve performance over reordering channels (either mechanisms to improve performance over reordering channels (either
due to random events, or to an attacker intentionally reordering due to random events, or to an attacker intentionally reordering
packets). Specifically, IPsec's sequence number may be used by the packets). Specifically, IPsec's sequence number may be used by the
decompressor to identify a packet as "sequentially late". This decompressor to identify a packet as "sequentially late". This
knowledge will increase the likelihood of successful decompression of knowledge will increase the likelihood of successful decompression of
a reordered packet. a reordered packet.
Additionally, RoHCoIPsec implementations should minimize the amount Additionally, RoHCoIPsec implementations should minimize the amount
of feedback sent from the decompressor to the compressor. If a ROHC of feedback sent from the decompressor to the compressor. If a ROHC
feedback channel is not used sparingly, the overall gains from feedback channel is not used sparingly, the overall gains from
RoHCoIPsec can be significantly reduced. For example, assume that RoHCoIPsec can be significantly reduced. More specifically, any
RoHC is operating in bi-directional Reliable mode (R-mode), and is
instantiated over an IPsec tunnel mode SA. In this scenario, any
feedback sent from the decompressor to the compressor must be feedback sent from the decompressor to the compressor must be
processed by IPsec, and tunneled back to the compressor (as processed by IPsec, and tunneled back to the compressor (as
designated by the SA associated with FEEDBACK_FOR). To address this designated by the SA associated with FEEDBACK_FOR). As such, several
need, several implementation considerations are offered: implementation considerations are offered:
o Eliminate feedback traffic altogether by operating only in RoHC o Eliminate feedback traffic altogether by operating only in RoHC
Unidirectional mode (U-mode) Unidirectional mode (U-mode)
o Piggyback RoHC feedback messages on traffic that normally o Piggyback RoHC feedback messages on traffic that normally
traverses the SA designated by FEEDBACK_FOR. traverses the SA designated by FEEDBACK_FOR.
Finally, it should be noted that all RoHCoIPsec implementations that
intend to reuse CIDs (i.e. remap a previously used but now retired
CID value in order to conserve CID space) must support the ROHC-DOWN
profile, as defined in [ROHC-DOWN]. This profile requires that a CID
value is shut-down before it is reused.
6.1.2. Initialization and Negotiation of the RoHC Channel 6.1.2. Initialization and Negotiation of the RoHC Channel
RoHC uses the underlying link layer (e.g., PPP) to negotiate RoHC RoHC uses the underlying link layer (e.g., PPP) to negotiate RoHC
channel parameters. In the case of RoHCoIPsec, channel parameters channel parameters. In the case of RoHCoIPsec, channel parameters
are negotiated by another mechanism. Specifically, initialization of are negotiated by another mechanism. Specifically, initialization of
the RoHC channel is either achieved manually (i.e., administratively the RoHC channel is either achieved manually (i.e., administratively
configured for manual SAs), or is performed by IPsec SA establishment configured for manual SAs), or is performed by IPsec SA establishment
protocols. The extensions required for IKEv2 to support RoHC protocols. The extensions required for IKEv2 to support RoHC
parameter negotiation are detailed in [IKE-ROHC]. parameter negotiation are detailed in [IKE-ROHC].
skipping to change at page 11, line 34 skipping to change at page 11, line 30
Finally, the authors would also like to thank Mr. Tom Conkle, Ms. Finally, the authors would also like to thank Mr. Tom Conkle, Ms.
Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen
Hamilton for their assistance in completing this work. Hamilton for their assistance in completing this work.
10. Informative References 10. Informative References
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (RoHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, July 2001.
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[ROHC-CRTP]
Bormann, et al., "A RoHC Profile for CRTP (RoHC-CRTP)",
work in progress , February 2007.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[AH] Kent, S., "IP Authentication Header", RFC 4302, [AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 3173, September 2001. Compression Protocol (IPComp)", RFC 3173, September 2001.
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression [ROHC2] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP, and Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP
UDP-Lite", work in progress , May 2007. Lite", work in progress , December 2007.
[IKE-ROHC] [IKE-ROHC]
Pezeshki, et al., "IKEv2 Extensions to Support Pezeshki, et al., "IKEv2 Extensions to Support
RoHCoIPsec", work in progress , August 2007. RoHCoIPsec", work in progress , February 2007.
[ROHC-RODR] [ROHC-RODR]
Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Pelletier, et al., "RObust Header Compression (ROHC): ROHC
Header Compression (ROHC): ROHC over Channels That Can over Channels That Can Reorder Packets", RFC 4224,
Reorder Packets", RFC 4224, January 2006. January 2006.
[ROHC-DOWN]
Bormann, C., "A ROHC Profile for CID shutdown (ROHC-
DOWN)", work in progress , July 2007.
[PROTOCOL] [PROTOCOL]
IANA, ""Assigned Internet Protocol Numbers", IANA registry IANA, ""Assigned Internet Protocol Numbers", IANA registry
at: http://www.iana.org/assignments/protocol-numbers", at: http://www.iana.org/assignments/protocol-numbers".
February 2007.
[IPSEC-ROHC] [IPSEC-ROHC]
Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec", Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec",
work in progress , August 2007. work in progress , February 2007.
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: ertekin_emre@bah.com Email: ertekin_emre@bah.com
 End of changes. 27 change blocks. 
66 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/