[rohc] Comments on current RoHC over IPSec draft
"Robert A. Stangarone Jr." <stangarr@spawar.navy.mil> Sun, 21 September 2008 20:08 UTC
Return-Path: <rohc-bounces@ietf.org>
X-Original-To: rohc-archive@megatron.ietf.org
Delivered-To: ietfarch-rohc-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D693A6BF3; Sun, 21 Sep 2008 13:08:52 -0700 (PDT)
X-Original-To: rohc@core3.amsl.com
Delivered-To: rohc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85E63A6BF3; Sun, 21 Sep 2008 13:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnsLRRgcdznP; Sun, 21 Sep 2008 13:08:49 -0700 (PDT)
Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id 2C2683A67E2; Sun, 21 Sep 2008 13:08:49 -0700 (PDT)
Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080921200902.GGPU8615.fed1rmmtao106.cox.net@fed1rmimpo01.cox.net>; Sun, 21 Sep 2008 16:09:02 -0400
Received: from localhost.localdomain ([70.181.130.184]) by fed1rmimpo01.cox.net with bizsmtp id HY911a00C3yrMdA03Y92RZ; Sun, 21 Sep 2008 16:09:03 -0400
X-Authority-Analysis: v=1.0 c=1 a=MSY2I4sHyF4A:10 a=LSkncEy7-U4A:10 a=48vgC7mUAAAA:8 a=8trJ58rFvmhiPR8WvsEA:9 a=J8_XVmOgLdAbaS8yL_MA:7 a=geqoUJJlGf4zLiqLoTDRxr_neYEA:4 a=LXqhN_b7XfkA:10 a=lZB815dzVvQA:10 a=kjO27gckG74A:10 a=iNuvWefPPzUA:10 a=ACBgD4iW9t8A:10 a=b8hG5vVbyAkA:10
X-CM-Score: 0.00
Message-ID: <48D6A96E.2020403@spawar.navy.mil>
Date: Sun, 21 Sep 2008 13:07:10 -0700
From: "Robert A. Stangarone Jr." <stangarr@spawar.navy.mil>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: rohc@ietf.org, christou_chris@bah.com, ertekin_emre@bah.com, ipsec@ietf.org, rohc-owner@ietf.org
References: <mailman.35.1221505204.24769.rohc@ietf.org>
In-Reply-To: <mailman.35.1221505204.24769.rohc@ietf.org>
Cc: stangarr@nkiconsulting.com
Subject: [rohc] Comments on current RoHC over IPSec draft
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rohc>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rohc-bounces@ietf.org
Errors-To: rohc-bounces@ietf.org
Hello Author and working group, I have the following comments on the current versions of the RoHC over IPsec drafts: draft-ietf-rohc-hcoipsec-08 - This document refers to the use of an Integrity Check Value (ICV) [section 6.1, Block B] to verify successful decompression of a ROHC packet. ROHC already provides CRC fields for this function. draft-ietf-rohc-ikev2-extensions-hcoipsec-06 - The authors are asserting that the ROHC Channel parameters much be negotiated, not signaled. A simpler approach would be for the device which will decompress traffic to signal to the device compressing the traffic its RoHC abilities. For example, from RFC 4995, section 5.1.2: LARGE_CIDS - Why is this even sent? The value given for MAX_CID should allow a device to determine the value of this RoHC Channel parameter. This parameter should not need to be negotiated, or signaled. MAX_CID - This parameter should be signaled by the end which will decompress the RoHC traffic. Ultimately, the decompressor's context storage space will limit how many contexts will be used. To support this assertion I provide the following MAX_CID cases: 1) The compressor has a larger MAX_CID than the decompresor. In this case the decompressor is the limiting factor on the MAX_CID. The compressor's MAX_CID will never be reached, and therefore is not important. 2) The compressor and decompressor have the same MAX_CID value. In this case the compressor's MAX_CID also does not matter because it is equal to the decompressor's MAX_CID. 3) The compressor has a smaller MAX_CID than the decompressor. In this case the compressor will never have a CID that is equal to the decompressor's MAX_CID, and therefore the decompressor does not need to know anything about the compressor's MAX_CID. The compressor will stop compressing flows once its MAX_CID is reached. PROFILES - This parameter should be signaled by the end which will decompress the RoHC traffic. By doing this the end which will compress the traffic knows what PROFILES may be used for compression. If the compressor supports PROFILES that the decompressor does not, it will never be able to use them with that decompressor anyway. If the decompressor supports PROFILES the compressor does not, the compressor will never use them either. FEEBACK_FOR - This should be signaled by the end doing decompression (and optionally sending feedback) to the end doing the decompression to indicate for which flow the feedback is sent. This is in agreement with the RFC. MRRU - This parameter is unnecessary. The external interface of the IPSec device should be able to determine the MTU of its link and fragment as needed/necessary. None of the RoHCv2 PROFILES (found in RFC 5225) allow for the use of MRRU, so why use it? The IKEv2 Notify Message Type [section 2.1] should only be sent once by each end during the IKE_AUTH and CREATE_CHILD_SA exchanges signaling the RoHC parameters. The standard Notify Payload header fields appear to be the same as those specified for IKEv2, but the Next Payload field is missing for some reason? Why? The fields specified to be included in the Notification Data field of the Notify Payload are as follows: MAX_CID MRRU - Why include MRRU field when ROHCv2 Profiles prohibit the use of segmentation (which is why you specify MRRU)? See MRRU comment above. MAX_HEADER - Only used for Profiles found in RFC 2507 (IPCOMP). None of the ROHCv2 Profiles utilize this value, why include it? PROFILE_LENGTH - Why do you need 16 bits to express the number of Profiles when the IETF has only allocated less than 20 Profile Identifiers? You can only use one variant of any Profile on a ROHC Channel per RFC 4995, section 5.1.2 (Per-Channel Parameters). PROFILES INTEGRITY ALGORITHMS - Why have Integrity Algorithms to "ensure the integrity of the decompressed packets" when you have ROHC CRCs to verify the decompression of packets? draft-ietf-rohc-ipsec-extensions-hcoipsec-02 - This document specifies the inclusion of ROHC Channel parameters into the SPD, including: MAX_CID, PROFILES, MRRU, MAX_HEADER. As ROHCv2 Profiles cannot use ROHC Segmentation, why have a MRRU parameter? Why include the MAX_HEADER parameter that is not used by ROHCv2 (nor RFC 3095) profiles? The document also specifies the inclusion of Integrity Algorithms into the SPD. See comment above on why these values don't appear to be useful. The SAD parameters specified include those specified for the SPD above, and also include the FEEDBACK_FOR parameter. The HAIPE IS draft spec and the IETF draft match on their approach on this parameter in both manual and dynamic SA creation cases. An argument is made in section 4 that the integrity check algorithm provides protection against the "...possibility of an invalidly decompressed packet to be forwarded ... into a protected domain." ROHCv2 Profiles already provide CRCs to validate or verify header decompression operations, and the ESP header provides an Authentication Data field which contains an ICV that is necessary to authenticate the packet. rohc-request@ietf.org wrote: > Send Rohc mailing list submissions to > rohc@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/rohc > or, via email, send a message with subject or body 'help' to > rohc-request@ietf.org > > You can reach the person managing the list at > rohc-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rohc digest..." > > > Today's Topics: > > 1. Re: Review of the RoHC over IPsec drafts (Ertekin, Emre [USA]) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 14 Sep 2008 23:40:53 -0400 > From: "Ertekin, Emre [USA]" <ertekin_emre@bah.com> > Subject: Re: [rohc] Review of the RoHC over IPsec drafts > To: "Yoav Nir" <ynir@checkpoint.com>, "Christou, Christos [USA]" > <christou_chris@bah.com>, <cabo@tzi.org> > Cc: ipsec@ietf.org, rohc@ietf.org, Yaron Sheffer > <yaronf@checkpoint.com> > Message-ID: > <37BDD2FAF2AEAE459C6C70FDC2892E4E03457938@MCLNEXVS05.resource.ds.bah.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi, Yoav, > > Thanks for your comments and review of our drafts. Please find our > responses below. > >> The three drafts are: >> >> * draft-ietf-rohc-hcoipsec - integration of RoHC over IPsec SAs >> * draft-ietf-rohc-ikev2-extensions-hcoipsec - IKEv2 extensions to >> negotiate RoHC over IPsec >> * draft-ietf-rohc-ipsec-extensions-hcoipsec - IPsec extenstions >> >> >> >> Overall the drafts drafts seem good, and in my opinion could offer a >> substantial benefit for IPsec tunnels, especially where the bandwidth > to >> one or both endpoints is constrained. Here's my comments. > > Thanks! > >> * The IKE & IPsec drafts talk about the use of integrity > algorithms to >> verify that decompression was successful. According to section 2.1 of > the >> IKEv2 draft, these algorithms are the same algorithms (with associated >> keys) as those used in IPsec. I can't figure out why you would want > this. > > The reason for this additional integrity-check is to mitigate scenarios > where intentional (severe) packet reordering or packet loss in the > unprotected network can cause the decompressor to invalidly decompress > packet headers (incorrectly reconstruct fields of a packet header), and > forward them into the protected domain. > > To mitigate this, we add the additional integrity algorithm to verify > that the decompression operation is successful. > > Note that since we are adding an additional ICV, the overall efficiency > gain of header compression is reduced. It may be desired not to > negotiate this additional RoHC integrity algorithm for the RoHC-enabled > SA, but this comes with the risk that compressed headers may be > invalidly decompressed and forwarded into the protected domain. > >> The entire packet, compressed header and data included, is already >> integrity protected by IPsec. An attacker can't flip any bits because > of >> the ESP ICV, so the RoHC ICV is simply there to detect decompression >> errors. I don't see why we need to exceed the recommendation in RFC > 4995 >> to use CRC. Even if you have decided that you want to upgrade error- >> detection ICV to a cryptographically strong one, HMAC doesn't offer > any >> benefit that I can see - you could use straight MD5 or SHA-1 without > any >> key, but I still don't see why CRC is not good enough. > > I think that Pasi responded to this in his email. We want to be able to > ensure (potentially to the level of the cryptographic strength > negotiated for IPsec) the integrity of all bits in the decompressed > header. > > Note, however, that the values negotiated for the integrity-check are > based on Integrity Algorithms defined in the Transform Type 3 registry. > Therefore, an implementation could negotiate the value of "0" (no > integrity-algorithm), and as you mentioned, rely on the built-in RoHC > CRC. > >> * The introduction to draft-ietf-rohc-hcoipsec-08 says that > "However, >> since current specifications for RoHC detail its operation on a > hop-by-hop >> basis, it may require extensions to enable its operation over IPsec > SAs.". >> This is not explained later. An IPsec tunnel is very much like a > single >> hop (for the tunneled traffic), so I don't see why special extensions >> would be needed. > > We'll clarify the introduction based on your comment. > > What we intended to indicate was that for RoHCoIPsec, there may be > multiple physical hops between compressor and decompressor (even though > it looks like a single hop from the IPsec perspective). Therefore, > RoHCv2 profiles that are tolerant to packet reordering/loss should be > used. > > Initial profiles of RoHC did not necessarily account for significant > packet reordering scenarios, since RoHC was initially designed to > operate over a single physical hop. > >> * Section 4 of draft-ietf-rohc-hcoipsec-08 needs some rewording. > Is >> the second sentence about the TFC feature of IPsec? About the padding >> feature of RoHC? About the problem in general? You might want to add >> discussion about whether it is recommended to use RoHC padding or > IPsec >> TFC to avoid the problem. > > It's about the problem in general. The second sentence was intended to > indicate that an ESP tunnel mode SA provides partial traffic flow > confidentiality, but that tunneling incurs additional packet overhead. > > I'm inclined to leave the text as-is; let me know if you still think it > needs to be modified. > >> * Section 5.2 of draft-ietf-rohc-hcoipsec (last paragraph) has > some >> strange text about ESP-NULL, which I don't understand. Why should > ESP-NULL >> be any different than any other ESP method? > > Fair comment. We'll delete this paragraph. > >> * There is, however, something to consider about ESP-NULL. Some >> middleboxes may want to inspect traffic that is encrypted with > ESP-NULL >> (see draft-grewal-ipsec-traffic-visibility-00). It's possible that > RoHC >> will cause those middleboxes to drop all traffic that is compressed, >> because they won't be able to parse the compressed headers. > > This is more of a question of policy rather than functionality. For > example, the middlebox may have a policy to drop ESP-NULL encrypted > packets whose inner-headers cannot be parsed. On the other hand, the > middlebox could have a policy that says inspect all ESP-NULL encrypted > packets, drop packets whose inner headers cannot be parsed, except for > those packets whose the NextHeader field is set to "RoHC". > >> * Section 6.1.2 says "f the RoHC protocol requires bi-directional >> communications, two SAs must be instantiated between the IPsec >> implementations." This is a non-issue, since IKE creates SAs in pairs >> anyways. So I don't see the point in the recommendation to use only > non- >> feedback profiles. You may want to mention that the decompressor needs > to >> relay feedback to the appropriate compressor > > Agreed. Later in the paragraph, we indicate: > > " Note that the requirement > for two SAs aligns with the operation of IKE, which creates SAs in > pairs by default." > > We'll modify the last sentence of the paragraph to indicate that the > decompressor associated with an inbound SA will relay feedback to the > compressor associated with the corresponding outbound SA. > >> Regarding the IKEv2 draft, I only have several comments about section > 2.1: >> * It's common for IKEv2 drafts to have at the beginning a figure > of >> the entire payload and then explain the various fields. > > Sure, we can add a figure illustrating the Notify payload. We actually > had this illustration in the -02 version of the draft, and then removed > it since it was identical to Figure 16 of RFC 4306. But, we'll add it > back. > >> * The explanation of the "Critical" bit is incorrect. It does not >> refer to the content of the payload, only to the type of the payload, > in >> this case "Notify". The bit MUST be off for Notify payloads, because > all >> IKEv2 implementations must support it. Similarly, there's not reason > to >> define the content of the reserved bits, because they're the same as > for >> any payload. > > Agreed--we have updated the draft to indicate that this bit if off. We > also removed the definition of the content of the reserved field. > >> * Protocol ID field: According to the first paragraph of 2.1, the >> notification is only in CCSA and IKE_AUTH. So there's no case where > this >> notification is used outside of the creation of the child SA, and > there's >> no need to ever set the protocol ID. > > Agreed--this is fixed. > > Best Regards, > Emre > > > ------------------------------ > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www.ietf.org/mailman/listinfo/rohc > > > End of Rohc Digest, Vol 53, Issue 7 > *********************************** _______________________________________________ Rohc mailing list Rohc@ietf.org https://www.ietf.org/mailman/listinfo/rohc
- [rohc] Comments on current RoHC over IPSec draft Robert A. Stangarone Jr.
- Re: [rohc] Comments on current RoHC over IPSec dr… Ertekin, Emre [USA]
- Re: [rohc] Comments on current RoHC over IPSec dr… Kristofer Sandlund
- Re: [rohc] Comments on current RoHC over IPSec dr… Carl Knutsson
- Re: [rohc] Comments on current RoHC over IPSec dr… Carl Knutsson