Re: [Hipsec] IPCOMP support in HIP

Miika Komu <miika.komu@ericsson.com> Thu, 10 March 2016 14:37 UTC

Return-Path: <miika.komu@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C3412D960 for <hipsec@ietfa.amsl.com>; Thu, 10 Mar 2016 06:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0bMIPyJ036U for <hipsec@ietfa.amsl.com>; Thu, 10 Mar 2016 06:37:23 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E5F12DA1B for <hipsec@ietf.org>; Thu, 10 Mar 2016 06:28:21 -0800 (PST)
X-AuditID: c1b4fb3a-f79ce6d000005138-79-56e18483d45b
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B8.19.20792.38481E65; Thu, 10 Mar 2016 15:28:19 +0100 (CET)
Received: from [131.160.36.157] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.248.2; Thu, 10 Mar 2016 15:28:17 +0100
To: hipsec@ietf.org
References: <56E03F56.5040300@htt-consult.com> <56E176AB.5070709@htt-consult.com>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <56E18482.1020206@ericsson.com>
Date: Thu, 10 Mar 2016 16:28:18 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E176AB.5070709@htt-consult.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050501070401090500060400"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7h25zy8MwgzdPtSymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCktZ5gKXjlWdEzQbmA8bNPFyMkhIWAi8excPzOELSZx4d56 NhBbSOAwo8SzozJdjFxA9hpGiWMLlrOCJIQFtCUer/0IZosIiEpM+XCaGaIhWOLmuTYwm01A S2LVnetgNr+ApMSGht1gNi9Q7+/eC4wgNouAqsT1eZfBlokKREg8mXuSEaJGUOLkzCcsXYwc HJwC+hKnt9eC3MAs0M0o8fJOPztIXEhAReLiseAJjAKzkHTMQlYGkmAWsJW4M3c3M4StLbFs 4Wso21pixq+DbBC2osSU7odQ9aYSr49+ZISwjSWWrfvLtoCRYxWjaHFqcXFuupGRXmpRZnJx cX6eXl5qySZGYOAf3PLbagfjweeOhxgFOBiVeHg/rHoQJsSaWFZcmXuIUQVozqMNqy8wSrHk 5eelKonwnq59GCbEm5JYWZValB9fVJqTWnyIUZqDRUmcl+3T5TAhgfTEktTs1NSC1CKYLBMH p1QDo8/8NQf6ylo2skkUGcQ9Y872dc7bfzePb127+64rua1f2mIN9xy7+03Fq7f4lMfhmWtD Be/+vVjMtLbtsH1Z/7z5Z2Jvib2uXPmv52Ps+ZJt5x2cC2ZWRbG9tXZaIFwceYenpuCsf2nE 7PUT/Z0igzOPr34osln5g9/aVYmyRzYaVQTpBzH6KLEUZyQaajEXFScCAIYPoJCEAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/Nws3hTc5LwB-JUD0dJrZTRON9Hc>
Subject: Re: [Hipsec] IPCOMP support in HIP
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2016 14:37:26 -0000

Hi,

I guess it could be a new "IPCOMP" transform similar to the ESP transform:

https://tools.ietf.org/html/rfc7402#section-5.1.2

I think R1-I2 would be enough, no need to confirm it in R2, similarly as 
with ESP transform:

https://tools.ietf.org/html/rfc7402#section-5.2.1

On 03/10/2016 03:29 PM, Robert Moskowitz wrote:
> I have found comp in TLS, RFC 3749, so HIP's ESP is the only one missing
> compression.  How did I miss that?  It should have been included in 7402
> as an option within ESP.
>
> I will figure out a way to get it into some RFC, but perhaps a little
> hashing out how it would work is called for first:
>
> IPCOMP parameter is a list.  The parameter number is higher than ESP;
> something like 4111.
>
> RFC 3173 defines the Compression Parameter Index as 2 bytes, so that
> would be the size of the values in the list.
>
> R1 would have a list of supported IPCOMP algorithms.
> I2 would have the selected algorithm, or a value of ZERO if none.
> R2 would have the confirmed value.
>
> NOTIFY could be used to set up IPCOMP (or change it) at a later time.
>
> Comments?
>
>
> On 03/09/2016 10:20 AM, Robert Moskowitz wrote:
>> Why did we not create a parameter to negotiate IPCOMP (currently RFC
>> 3173)?
>>
>> In IKEv2 it is negotiated in NOTIFY messages, not the basic exchange
>> and becomes part of the daughter SA(s).
>>
>> On contrained networks, IPCOMP could well be of value.  Also if HIP is
>> used to establish the SAs for SSE (draft-moskowitz-sse-02.txt) and the
>> SSE payload is XML, then IPCOMP (or some variant tbd) may be a good
>> thing.
>>
>> So....
>>
>> Again, why no IPCOMP parameter?
>>
>> IPCOMP parameter handled like ESP parameter or like in IKEv2?
>>
>> How to add an IPCOMP parameter?  If I write a draft for a Generic
>> Protocol Compression, I can include a section that defines an
>> IPCOMP/GPCOMP parameter.  Or I can add it to DEX (don' want to add
>> that at this point, EC25519 fits, IPCOMP is expanding the protocol).
>>
>> Comments?
>>
>>
>> _______________________________________________
>> Hipsec mailing list
>> Hipsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/hipsec
>>
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec