[IPsec] Review of the RoHC over IPsec drafts
Yoav Nir <ynir@checkpoint.com> Mon, 08 September 2008 13:35 UTC
Return-Path: <ipsec-bounces@ietf.org>
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D0228C0E6; Mon, 8 Sep 2008 06:35:15 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067183A6A46; Mon, 8 Sep 2008 06:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level:
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 4-it-zSKjAQu; Mon, 8 Sep 2008 06:35:08 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7C3023A695C; Mon, 8 Sep 2008 06:35:07 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 61A6B294004; Mon, 8 Sep 2008 16:35:09 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 42834294001; Mon, 8 Sep 2008 16:35:08 +0300 (IDT)
Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m88DZ7P4018340; Mon, 8 Sep 2008 16:35:07 +0300 (IDT)
Message-Id: <674C0769-E278-4A59-A490-7634F2B0FF83@checkpoint.com>
From: Yoav Nir <ynir@checkpoint.com>
To: pezeshki_jonah@bah.com, ertekin_emre@bah.com, jasani_rohan@bah.com, christou_chris@bah.com, cabo@tzi.org
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Mon, 08 Sep 2008 16:35:00 +0300
X-Mailer: Apple Mail (2.928.1)
Cc: ipsec@ietf.org, rohc@ietf.org
Subject: [IPsec] Review of the RoHC over IPsec drafts
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0054972141=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org
Hi all At Yaron's request I've gone over the three drafts related to RoHC over IPsec tunnels. 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. 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 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. 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. 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. 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? 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. 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 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. 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. 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.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
- [IPsec] Review of the RoHC over IPsec drafts Yoav Nir
- [IPsec] Review of the RoHC over IPsec drafts Tero Kivinen
- Re: [IPsec] Review of the RoHC over IPsec drafts Yaron Sheffer
- Re: [IPsec] Review of the RoHC over IPsec drafts Yoav Nir
- Re: [IPsec] Review of the RoHC over IPsec drafts Pasi.Eronen
- Re: [IPsec] Review of the RoHC over IPsec drafts Ertekin, Emre [USA]