From nobody Tue Mar 1 13:56:59 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA501B40D2 for ; Tue, 1 Mar 2016 13:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 VZ8CiS75G0CV for ; Tue, 1 Mar 2016 13:56:54 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2471B415D for ; Tue, 1 Mar 2016 13:56:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9F70C62152; Tue, 1 Mar 2016 16:56:49 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j6CGqNvG6fAv; Tue, 1 Mar 2016 16:56:43 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 5A0206081A; Tue, 1 Mar 2016 16:56:43 -0500 (EST) To: Gonzalo Camarillo , HIP References: <56C1B871.6090000@ericsson.com> <56D54BBC.2090407@ericsson.com> From: Robert Moskowitz Message-ID: <56D61019.8040203@htt-consult.com> Date: Tue, 1 Mar 2016 16:56:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56D54BBC.2090407@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Hipsec] New WG item: HIP Diet EXchange (DEX) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 21:56:56 -0000 I have uploaded the current draft with the name change. I will look at what it will take to add Curve25519 (RFC 7748). On 03/01/2016 02:58 AM, Gonzalo Camarillo wrote: > Authors of draft-moskowitz-hip-rg-dex, > > could you please revise the draft as a WG item? Please, use the > following file name in your submission: > > draft-ietf-hip-dex-00 > > Thanks, > > Gonzalo > > > On 15/02/2016 1:37 PM, Gonzalo Camarillo wrote: >> Folks, >> >> I have talked with our AD and he is OK with adding the following >> milestone to our charter: >> >> o Develop a standards track specification of a light-weight HIP exchange >> >> The plan would be to take the following draft as the WG item associated >> with the milestone: >> >> https://datatracker.ietf.org/doc/draft-moskowitz-hip-dex/ >> >> Please, let us know if you have comments (positive or negative) on this. >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> 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 > From nobody Wed Mar 2 00:20:53 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C377F1A8A95; Wed, 2 Mar 2016 00:20:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160302082051.18750.37282.idtracker@ietfa.amsl.com> Date: Wed, 02 Mar 2016 00:20:51 -0800 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 08:20:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Filename : draft-ietf-hip-dex-00.txt Pages : 46 Date : 2016-03-01 Abstract: This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to HIPv2. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-dex-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 2 00:21:25 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DFA1A8A86 for ; Wed, 2 Mar 2016 00:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 Jo3qfHdLSChm for ; Wed, 2 Mar 2016 00:21:22 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFC31A8A90 for ; Wed, 2 Mar 2016 00:21:21 -0800 (PST) X-AuditID: c1b4fb30-f79096d000002f68-53-56d6a27fc888 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3B.29.12136.F72A6D65; Wed, 2 Mar 2016 09:21:19 +0100 (CET) Received: from [131.160.36.142] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.248.2; Wed, 2 Mar 2016 09:21:19 +0100 To: Robert Moskowitz , HIP References: <56C1B871.6090000@ericsson.com> <56D54BBC.2090407@ericsson.com> <56D61019.8040203@htt-consult.com> From: Gonzalo Camarillo Message-ID: <56D6A27F.4040905@ericsson.com> Date: Wed, 2 Mar 2016 10:21:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56D61019.8040203@htt-consult.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7pW79omthBpufmVpMXTSZ2aJh3WdG ByaP3ZOa2D2WLPnJFMAUxWWTkpqTWZZapG+XwJVx9toktoIN3BVzz+9jb2BcwtnFyMkhIWAi cWPXczYIW0ziwr31QDYXh5DAYUaJp98/s0M4qxklrm+/xApSJSxgJfF3zUawDhEBR4l/3Q/A bCGBAoktZ04xgdhsAhYSW27dZwGxeQW0JdYsvsoIYrMIqEj8f7sJLC4qECNxsfMIE0SNoMTJ mU/A4pwC+hLbnp0Esjk4mAU0Jdbv0gcJMwvIS2x/O4cZYpW2xPJnLSwTGAVmIemehdAxC0nH AkbmVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBQXlwy2+DHYwvnzseYhTgYFTi4f0gdy1M iDWxrLgy9xCjBAezkgivcS9QiDclsbIqtSg/vqg0J7X4EKM0B4uSOC/rp8thQgLpiSWp2amp BalFMFkmDk6pBka9vtqHHB3flph+tZzkcNKu7d598caCS/wi0hHK2f9DhXZ5X59wYZKc4ey/ C45cLM6cNFN+3iyNnyFZqyd3VCyd0t8vGXRv8SLBLuZFuwvtmq8YT/5rH/hIwSRv9gyDpdvq s19IOqjUpAROSeFotHpr/6Lyxx2xD2KRoSlpPgH2Uk84/2Xy1yixFGckGmoxFxUnAgB84pKE RgIAAA== Archived-At: Subject: Re: [Hipsec] New WG item: HIP Diet EXchange (DEX) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 08:21:23 -0000 Thanks, Bob! I have just approved the submission. https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ Cheers, Gonzalo On 01/03/2016 11:56 PM, Robert Moskowitz wrote: > I have uploaded the current draft with the name change. > > I will look at what it will take to add Curve25519 (RFC 7748). > > On 03/01/2016 02:58 AM, Gonzalo Camarillo wrote: >> Authors of draft-moskowitz-hip-rg-dex, >> >> could you please revise the draft as a WG item? Please, use the >> following file name in your submission: >> >> draft-ietf-hip-dex-00 >> >> Thanks, >> >> Gonzalo >> >> >> On 15/02/2016 1:37 PM, Gonzalo Camarillo wrote: >>> Folks, >>> >>> I have talked with our AD and he is OK with adding the following >>> milestone to our charter: >>> >>> o Develop a standards track specification of a light-weight HIP exchange >>> >>> The plan would be to take the following draft as the WG item associated >>> with the milestone: >>> >>> https://datatracker.ietf.org/doc/draft-moskowitz-hip-dex/ >>> >>> Please, let us know if you have comments (positive or negative) on this. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> 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 >> > From nobody Wed Mar 2 05:51:36 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604E21A88E6 for ; Wed, 2 Mar 2016 05:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 shFGKXOAiZmV for ; Wed, 2 Mar 2016 05:51:32 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B788E1B29E7 for ; Wed, 2 Mar 2016 05:51:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id BB74D6219A; Wed, 2 Mar 2016 08:51:31 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TR5+CWabkS7P; Wed, 2 Mar 2016 08:51:24 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1C39A6218A; Wed, 2 Mar 2016 08:51:24 -0500 (EST) To: Gonzalo Camarillo , HIP References: <56C1B871.6090000@ericsson.com> <56D54BBC.2090407@ericsson.com> <56D61019.8040203@htt-consult.com> <56D6A27F.4040905@ericsson.com> From: Robert Moskowitz Message-ID: <56D6EFD8.1070106@htt-consult.com> Date: Wed, 2 Mar 2016 08:51:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56D6A27F.4040905@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Hipsec] New WG item: HIP Diet EXchange (DEX) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 13:51:35 -0000 I would appreciate it if people could take a read through the draft. Particularly compare it to BEXv2 to ensure that Rene and I have the text aligned. There may be some late changes we missed. On 03/02/2016 03:21 AM, Gonzalo Camarillo wrote: > Thanks, Bob! I have just approved the submission. > > https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ > > Cheers, > > Gonzalo > > On 01/03/2016 11:56 PM, Robert Moskowitz wrote: >> I have uploaded the current draft with the name change. >> >> I will look at what it will take to add Curve25519 (RFC 7748). >> >> On 03/01/2016 02:58 AM, Gonzalo Camarillo wrote: >>> Authors of draft-moskowitz-hip-rg-dex, >>> >>> could you please revise the draft as a WG item? Please, use the >>> following file name in your submission: >>> >>> draft-ietf-hip-dex-00 >>> >>> Thanks, >>> >>> Gonzalo >>> >>> >>> On 15/02/2016 1:37 PM, Gonzalo Camarillo wrote: >>>> Folks, >>>> >>>> I have talked with our AD and he is OK with adding the following >>>> milestone to our charter: >>>> >>>> o Develop a standards track specification of a light-weight HIP exchange >>>> >>>> The plan would be to take the following draft as the WG item associated >>>> with the milestone: >>>> >>>> https://datatracker.ietf.org/doc/draft-moskowitz-hip-dex/ >>>> >>>> Please, let us know if you have comments (positive or negative) on this. >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> _______________________________________________ >>>> 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 >>> From nobody Mon Mar 7 04:35:14 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4285E1B4055 for ; Mon, 7 Mar 2016 04:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 dHal11dyj3vm for ; Mon, 7 Mar 2016 04:35:11 -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 994D81B4053 for ; Mon, 7 Mar 2016 04:35:10 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-b6-56dd757c2eee Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FC.97.20792.C757DD65; Mon, 7 Mar 2016 13:35:08 +0100 (CET) Received: from [131.160.36.131] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.248.2; Mon, 7 Mar 2016 13:35:07 +0100 To: Miika Komu , References: <56CDBDA1.7050207@ericsson.com> <3CEE85EA-C996-4B28-B0A3-DA8B158BD159@temperednetworks.com> <56D1630A.7000209@ericsson.com> <56D45895.2060503@ericsson.com> From: Gonzalo Camarillo Message-ID: <56DD757B.8050002@ericsson.com> Date: Mon, 7 Mar 2016 14:35:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56D45895.2060503@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2K7gW5N6d0wg61bRSymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPZX15kKfglV7LzyhLWBsYe/i5GTQ0LAROLamc3MELaYxIV7 69m6GLk4hAQOM0r87psC5axmlGibsZ8dpEpYwF7i5L5bYLaIgLXEh8vLmUBsIYHXjBLTXhiC 2GwCFhJbbt1nAbF5BbQlJk1dAFTPwcEioCLxbnIxSFhUIEbiYucRJogSQYmTM5+AlXMK6EjM u/mREcRmFjCQOLJoDiuELS+x/e0cZohV2hLLn7WwTGAUmIWkfRaSlllIWhYwMq9iFC1OLS7O TTcy0kstykwuLs7P08tLLdnECAzBg1t+W+1gPPjc8RCjAAejEg/vB7W7YUKsiWXFlbmHGCU4 mJVEeDeUAIV4UxIrq1KL8uOLSnNSiw8xSnOwKInzsn26HCYkkJ5YkpqdmlqQWgSTZeLglGpg 9GXsvBhj27ekS2J3lHJI7L2U3Y+/Ncc2Sz2+ONGrflaOmcr60p2u37UW9DTefm7z+W3UisOX DBNWHXhlOq3t1fa9i97s80/P4Tzft+lk0WrX/05pm0x+dcvbddbpiLyYruvRMK3pAb/CNJeU 8pAO2z0eC/5P+2l4Or40fd+24FlbM9yv679xV2Ipzkg01GIuKk4EAFPX5Ws9AgAA Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 12:35:13 -0000 Hi, I have just talked with Miika and he has volunteered to take the pen and add the necessary clarifications to the draft so that it is more readable. Thanks, Miika! First he will look into adding clarifications to the existing draft while still referencing the old RFC. If the group is not happy with the readability after the editorial pass (or our AD does not finally let us downref the old RFC), we can consider bringing material from the old RFC directly into the new one. I would also like the group to comment on the following two proposals: 1) the draft will allow implementers to use HIP native relays only. In addition, the use of STUN and TURN relays will be optional. 2) in addition to covering the base exchange, the draft will also cover the mobility readdressing exchange. Thanks, Gonzalo On 29/02/2016 4:41 PM, Miika Komu wrote: > Hi, > > On 02/27/2016 10:49 AM, Gonzalo Camarillo wrote: >> Hi Jeff, >> >> thanks for your feedback. >> >>> Regarding pros/cons: >>> How widely-deployed is STUN/TURN? Are public servers widespread? >> >> there are several of them. They are mostly used for VoIP. You can google >> for "public stun turn servers" or something similar. There are a few >> lists out there. > > I guess the situation is like this: > > HIP control plane relay: > * new critical infrastructure that needs to be deployed anyway (TURN > server cannot be used for this) > > Gathering of address candidates: > * from a STUN server (many available) > * ...or from control plane relay registration (which is mandatory anyway) > > Data plane relay: > * using TURN server (it seems some are available) > * ...or using the ESP relay as specified in native NAT spec (none > deployed, but I guess could co-locate with the HIP control plane relay) > > So, the critical part are the HIP control plane relays which provide > also similar functionality as STUN servers (i.e. provide server > reflexive candidates). So I guess the question boils down to the > availability of TURN servers. > > P.S. Nothing really prevents to use STUN servers to discover address > candidates in the native NAT traversal version. The discovery process is > independent of the NAT penetration process. > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Mon Mar 7 13:32:04 2016 Return-Path: X-Original-To: hipsec@ietfc.amsl.com Delivered-To: hipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E07081CDBF1 for ; Mon, 7 Mar 2016 13:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdxQCy2mI4WV for ; Mon, 7 Mar 2016 13:31:58 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id EA10B1CDBB1 for ; Mon, 7 Mar 2016 13:31:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id ED0B8622C5 for ; Mon, 7 Mar 2016 16:31:56 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Oz2TluprXIaJ for ; Mon, 7 Mar 2016 16:31:48 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2D606622B8 for ; Mon, 7 Mar 2016 16:31:48 -0500 (EST) To: HIP From: Robert Moskowitz Message-ID: <56DDF341.9040901@htt-consult.com> Date: Mon, 7 Mar 2016 16:31:45 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030004080005050302010704" Archived-At: Subject: [Hipsec] Status of IEEE 802.15.9 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 21:32:02 -0000 This is a multi-part message in MIME format. --------------030004080005050302010704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit iEEE 802.15.9 is Key Management Transport for 802.15.4. It calls out support for a number of KMPs defined here in the IETF, including both HIP BEX and DEX. This is one of the many reasons why I want to get HIP DEX published as an RFC, as only RFCs can be referenced in a published IEEE standard. So today I receive the following good news: -------- Forwarded Message -------- Subject: Fwd: 802.15.9-2016 Approval Notification Date: Mon, 07 Mar 2016 15:56:48 -0500 From: Bob Heile To: rgm@labs.htt-consult.com, peter@AKAYLA.COM, kivinen@iki.fi, pat.kinney@ieee.org, bheile@ieee.org Congratulations Guys Regards Bob > Date: Mon, 7 Mar 2016 10:06:50 -0500 > Subject: 802.15.9-2016 Approval Notificatioin > From: Karen Evangelista > To: "Heile Bob Ph.,D" > Cc: "James P. K. Gilb" , Jonathan Goldberg > , > Michelle Turner , Kim Breitfelder > , > Patrick Gibbons > > 7 March 2016 > > Robert Heile, > > cc: James Gilb, C/LM Sponsor > Jonathan Goldberg, Program Manager > Kim Breitfelder, Director, Content Production and Management > > RE: NEW P802.15.9 (C/LM) Recommended Practice for Transport of Key > Management Protocol (KMP) Datagrams > > Dear Robert, > > I am pleased to inform you that P802.15.9 was approved as a new > standard by the IEEE-SA Standards Board on 4 March 2016. A copy of the > document will be forwarded to the Standards Publications Department. > The editor assigned to work on the project will contact you. > > An approved IEEE standard will remain active for ten years. If the > Sponsor does not complete a revision process within ten years, the > standard will be transferred to inactive status. > > Please contact me if you have any questions prior to speaking with > your editor. > > Sincerely, > ************************************************** > Karen M. Evangelista > IEEE-SA Governance, Senior Administrator > IEEE Standards Activities Department > 445 Hoes Lane > Piscataway, NJ 08854-4141 USA > Tel: +1 732 562 3854 > k.evangelista@ieee.org > ************************************************** Bob Heile, Ph.D Director of Standards, Wi-SUN Alliance Chair, IEEE 802.15 Working Group on Wireless Specialty Networks Chair IEEE 2030.5 Working Group for Smart Energy Profile 2 Co-Chair IEEE P2030 Task Force 3 on Smartgrid Communications 11 Robert Toner Blvd, Suite 5-301 North Attleboro, MA 02763 USA Mobile: +1-781-929-4832 email: bheile@ieee.org --------------030004080005050302010704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit iEEE 802.15.9 is Key Management Transport for 802.15.4.  It calls out support for a number of KMPs defined here in the IETF, including both HIP BEX and DEX.  This is one of the many reasons why I want to get HIP DEX published as an RFC, as only RFCs can be referenced in a published IEEE standard.  So today I receive the following good news:



-------- Forwarded Message --------
Subject: Fwd: 802.15.9-2016 Approval Notification
Date: Mon, 07 Mar 2016 15:56:48 -0500
From: Bob Heile <bheile@ieee.org>
To: rgm@labs.htt-consult.com, peter@AKAYLA.COM, kivinen@iki.fi, pat.kinney@ieee.org, bheile@ieee.org


Congratulations Guys

Regards

Bob
Date: Mon, 7 Mar 2016 10:06:50 -0500
Subject: 802.15.9-2016 Approval Notificatioin
From: Karen Evangelista <k.evangelista@ieee.org>
To: "Heile Bob Ph.,D" <bheile@ieee.org>
Cc: "James P. K. Gilb" <gilb@ieee.org>, Jonathan Goldberg <goldberg.j@ieee.org>,
        Michelle Turner <m.d.turner@ieee.org>, Kim Breitfelder <k.breitfelder@ieee.org>,
        Patrick Gibbons <p.gibbons@ieee.org>

7 March 2016

Robert Heile,

cc: James Gilb, C/LM Sponsor
Jonathan Goldberg, Program Manager
Kim Breitfelder, Director, Content Production and Management

RE:  NEW P802.15.9 (C/LM) Recommended Practice for Transport of Key Management Protocol (KMP) Datagrams

Dear Robert,

I am pleased to inform you that P802.15.9 was approved as a new standard by the IEEE-SA Standards Board on 4 March 2016. A copy of the document will be forwarded to the Standards Publications Department. The editor assigned to work on the project will contact you.

An approved IEEE standard will remain active for ten years. If the Sponsor does not complete a revision process within ten years, the standard will be transferred to inactive status.

Please contact me if you have any questions prior to speaking with
your editor.

Sincerely,
**************************************************
Karen M. Evangelista
IEEE-SA Governance, Senior Administrator
IEEE Standards Activities Department
445 Hoes Lane
Piscataway, NJ 08854-4141 USA
Tel: +1 732 562 3854
k.evangelista@ieee.org
**************************************************


Bob Heile, Ph.D

Director of Standards, Wi-SUN Alliance
Chair, IEEE 802.15 Working Group on Wireless Specialty Networks
Chair IEEE 2030.5 Working Group for Smart Energy Profile 2
Co-Chair IEEE P2030 Task Force 3 on Smartgrid Communications

11 Robert Toner Blvd, Suite 5-301
North Attleboro, MA  02763   USA
Mobile: +1-781-929-4832
email:   bheile@ieee.org



--------------030004080005050302010704-- From nobody Wed Mar 9 07:38:52 2016 Return-Path: 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 B861012D70B for ; Wed, 9 Mar 2016 07:38:17 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFbw0pmZ4B7f for ; Wed, 9 Mar 2016 07:38:16 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9346612E0F7 for ; Wed, 9 Mar 2016 07:21:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 853E9621A2 for ; Wed, 9 Mar 2016 10:21:02 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pqYfY9oHoVHY for ; Wed, 9 Mar 2016 10:20:58 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id F3C67621A0 for ; Wed, 9 Mar 2016 10:20:57 -0500 (EST) To: hipsec@ietf.org From: Robert Moskowitz Message-ID: <56E03F56.5040300@htt-consult.com> Date: Wed, 9 Mar 2016 10:20:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 15:38:17 -0000 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? From nobody Thu Mar 10 05:29:39 2016 Return-Path: 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 0212D12D78F for ; Thu, 10 Mar 2016 05:29:38 -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, RP_MATCHES_RCVD=-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 wVe7aoIEb5so for ; Thu, 10 Mar 2016 05:29:30 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7656E12D790 for ; Thu, 10 Mar 2016 05:29:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 003B7621A5 for ; Thu, 10 Mar 2016 08:29:25 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Y0xA-6Y8WenK for ; Thu, 10 Mar 2016 08:29:20 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9949B621A3 for ; Thu, 10 Mar 2016 08:29:18 -0500 (EST) To: hipsec@ietf.org References: <56E03F56.5040300@htt-consult.com> From: Robert Moskowitz Message-ID: <56E176AB.5070709@htt-consult.com> Date: Thu, 10 Mar 2016 08:29:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56E03F56.5040300@htt-consult.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 13:29:38 -0000 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 > From nobody Thu Mar 10 06:37:27 2016 Return-Path: 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 ; 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 ; 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 ; 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: References: <56E03F56.5040300@htt-consult.com> <56E176AB.5070709@htt-consult.com> From: Miika Komu 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 14:37:26 -0000 --------------ms050501070401090500060400 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable 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 missin= g > compression. How did I miss that? It should have been included in 740= 2 > 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 --------------ms050501070401090500060400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzEwMTQyODE4 WjAvBgkqhkiG9w0BCQQxIgQgSVtstkrPiMPW3+l9jr68wz0VnaV9uVQUeqnfqNdDvnowXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBryXtEiIft aYLpudf+EYZlFFtGdgrB4751+zvLnw/V3bxdUVFA2i3NxSoIK3ScEwwLBW9e6K81MWv/RjHD mdda8ApCSFvCF1qTVKGgRRmsBCrjOTsshb7awoYfTnJ1SXE86EpvhW70Ed7B1Jmo6LAPBJhZ GoAou5LGveyL3AKmydNc6MHDicHA2F5te0DgrBGcCzhMSWHiiUpPdL38cGSH3nLixGusi9Ne 0fs52qfX+Vzx27d0+pmJLNvGBPts7eszTj2k/qYeTfc9NBLbk7UjD4RVf/87D5+PoSqmcUJM b6QGgmekAAX4qUxd6hn2mfXv1JBgDmV7O4tPReSQh5kfAAAAAAAA --------------ms050501070401090500060400-- From nobody Thu Mar 10 11:10:47 2016 Return-Path: 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 AFC7412DBF4 for ; Thu, 10 Mar 2016 11:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-hipsec@employees.org header.d=employees.org 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 RNdxL6UFLdCd for ; Thu, 10 Mar 2016 11:10:43 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C784B12DBEF for ; Thu, 10 Mar 2016 11:10:43 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 2AA0FD7893; Thu, 10 Mar 2016 11:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=Ukk1lpd1sNYQvswW4KEpK1Zf2dk=; b=gd 3T0QKbZyuIdGtwYm0GSLSL8Iav3+9uWZw+rNZFCGjZ/MyMm3fYtqKBwzw6uJZbYy OFG5BMVIb3gMnyhsiSm20aq4LRzvScyGPgJn7NsFND4X+NfU3mpGWEP12wGb9tPi fgqsPozOs3ZsB0na6aeBHMo12+uhAqq//mpyAapVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=MjyLS8mZ4HtsusWTJ465fEShZPLa avBBG8H7gL+J70thN2UHGOsX/Ed6NyTcKG/dEL581cFJx52LycJn327xxR+dpUuQ 0koUe6SeO4yg69DnXSPsIDKA140qlMTQF8BOvp1AzNnxFoF2FR6IDfZGstBogZBl +UWqaUlQmBGuFpc= Received: by cowbell.employees.org (Postfix, from userid 1736) id 1ABB0D7882; Thu, 10 Mar 2016 11:10:41 -0800 (PST) Date: Thu, 10 Mar 2016 19:10:41 +0000 From: Derek Fawcus To: Robert Moskowitz Message-ID: <20160310191041.GA14546@cowbell.employees.org> Mail-Followup-To: Robert Moskowitz , hipsec@ietf.org References: <56E03F56.5040300@htt-consult.com> <56E176AB.5070709@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E176AB.5070709@htt-consult.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: hipsec@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 19:10:45 -0000 On Thu, Mar 10, 2016 at 08:29:15AM -0500, 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. Hasn't use of compression with TLS largely been abandoned now? Simply because one or more of the recently published exploits depended upon it, such that now one is recommended to disable compression? So if TLS is avoiding compression, why is normal IPsec still using it? It is because the compositions of compression and encryption used in IPsec are safe, or has no simply tried (or not published) such attacks for IPsec? DF From nobody Thu Mar 10 11:19:00 2016 Return-Path: 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 B267F12D584 for ; Thu, 10 Mar 2016 11:18:58 -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, RP_MATCHES_RCVD=-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 MMq8gZRJ5Ll1 for ; Thu, 10 Mar 2016 11:18:56 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F6B12D776 for ; Thu, 10 Mar 2016 11:18:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 10DA6621F9 for ; Thu, 10 Mar 2016 14:18:55 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hdQBvyyzqhZZ for ; Thu, 10 Mar 2016 14:18:53 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CE303621F8 for ; Thu, 10 Mar 2016 14:18:52 -0500 (EST) To: hipsec@ietf.org References: <56E03F56.5040300@htt-consult.com> <56E176AB.5070709@htt-consult.com> <20160310191041.GA14546@cowbell.employees.org> From: Robert Moskowitz Message-ID: <56E1C89B.5040509@htt-consult.com> Date: Thu, 10 Mar 2016 14:18:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160310191041.GA14546@cowbell.employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 19:18:58 -0000 Fair point. I really cannot convert TLS specifications to packet content. I suspect there are things exposed? With IPCOMP, it is all within the EXP encrypted block. It is known text, for the most part and would be open to known text attacks. But then there is always a fair amount of known text at the beginning of an ESP payload. How would this be different? I do suspect that TLS is different in how it does compression, and if it is being abandoned, so sad. It should be fixed because.... Even 5G will not provide unlimited bandwidth, and XML tends to be very compressable. Plus with DEX on constrained networks, compression is even more valuable. But can you point me to a paper on the TLS compression attack? On 03/10/2016 02:10 PM, Derek Fawcus wrote: > On Thu, Mar 10, 2016 at 08:29:15AM -0500, 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. > Hasn't use of compression with TLS largely been abandoned now? > Simply because one or more of the recently published exploits depended upon > it, such that now one is recommended to disable compression? > > So if TLS is avoiding compression, why is normal IPsec still using it? > It is because the compositions of compression and encryption used in IPsec > are safe, or has no simply tried (or not published) such attacks for IPsec? > > DF > From nobody Thu Mar 10 12:13:35 2016 Return-Path: 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 825AB12DCA9 for ; Thu, 10 Mar 2016 12:13:34 -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, RP_MATCHES_RCVD=-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 JT17FXz3JVEH for ; Thu, 10 Mar 2016 12:13:33 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6604412DCA8 for ; Thu, 10 Mar 2016 12:13:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 77BDD6220D for ; Thu, 10 Mar 2016 15:13:32 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gv+EkvECL8sg for ; Thu, 10 Mar 2016 15:13:27 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2A3D16220C for ; Thu, 10 Mar 2016 15:13:27 -0500 (EST) To: hipsec@ietf.org References: <56E03F56.5040300@htt-consult.com> <56E176AB.5070709@htt-consult.com> <20160310191041.GA14546@cowbell.employees.org> From: Robert Moskowitz Message-ID: <56E1D565.5060605@htt-consult.com> Date: Thu, 10 Mar 2016 15:13:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160310191041.GA14546@cowbell.employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 20:13:34 -0000 I have looked at both the CRIME and BREACH attacks and neither would work against IPCOMP within ESP. TLS and HTTP compression are softly done... It DOES change some of my thoughts about compression as a XML option for use in DOTS. That is pretty much what CRIME is attacking. Rather you have to take your outer envelope that contains your XML and compress the whole thing. On 03/10/2016 02:10 PM, Derek Fawcus wrote: > On Thu, Mar 10, 2016 at 08:29:15AM -0500, 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. > Hasn't use of compression with TLS largely been abandoned now? > Simply because one or more of the recently published exploits depended upon > it, such that now one is recommended to disable compression? > > So if TLS is avoiding compression, why is normal IPsec still using it? > It is because the compositions of compression and encryption used in IPsec > are safe, or has no simply tried (or not published) such attacks for IPsec? > > DF > From nobody Thu Mar 10 12:52:27 2016 Return-Path: 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 EA05512DCFB for ; Thu, 10 Mar 2016 12:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-hipsec@employees.org header.d=employees.org 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 RV7ivGyHtJXA for ; Thu, 10 Mar 2016 12:52:23 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D5D12DCFA for ; Thu, 10 Mar 2016 12:52:23 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 3BD21D7895; Thu, 10 Mar 2016 12:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=F0dGbJZeOR1x2ch+f8ONdA+UpNA=; b=cE pMxsgq2wAMVt6gTwJ0t4TSK9vaWK9y7t4Uv5F0B7P1ZBN6FS9Ffitp/eZrou7lQw FzqJ46sGNN1vxn7kSQTHRuEEnS7bBXjlJ/M6O0CPCbzRvtPNd5/aGSODWXuCdR0T uzo6ZbCzt/QXIWA9E+7pOA7rTusVhI37EHGxpwJ7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=ejA6o0r+s6wJb/C0QC6b6FWLn45n ICmPFXnnlmyAvW2EqrFsNnNkfHxTbnZb3B6tyjYQwsqfyWF1ffda15jsHlf7hDSO oKz8R+ddQ/fIQTRgVNJuE5gMwB3yXXieJv+j0E9qkQfIi2PtHnmSegOaxCB+qv4q L+qLa9K0QI5+mEI= Received: by cowbell.employees.org (Postfix, from userid 1736) id 37249D7893; Thu, 10 Mar 2016 12:52:22 -0800 (PST) Date: Thu, 10 Mar 2016 20:52:22 +0000 From: Derek Fawcus To: Robert Moskowitz Message-ID: <20160310205222.GA39508@cowbell.employees.org> Mail-Followup-To: Robert Moskowitz , hipsec@ietf.org References: <56E03F56.5040300@htt-consult.com> <56E176AB.5070709@htt-consult.com> <20160310191041.GA14546@cowbell.employees.org> <56E1C89B.5040509@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E1C89B.5040509@htt-consult.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: hipsec@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 20:52:26 -0000 On Thu, Mar 10, 2016 at 02:18:51pm -0500, Robert Moskowitz wrote: > Fair point. I really cannot convert TLS specifications to packet > content. I suspect there are things exposed? [snip] > I do suspect that TLS is different in how it does compression, and if it > is being abandoned, so sad. quite possibly. > But can you point me to a paper on the TLS compression attack? I'm afraid not, I just recall reading up on some of the TLS attacks when they were publicised, and seeing that some of them were related to compression. A bit of poking around though yielded: http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf I also spotted this, but it doesn't add much: https://www.cosic.esat.kuleuven.be/ecrypt/provpriv2012/abstracts/barghavan.pdf I did avail myself of google before my prior email, it suggested CRIME and BREACH. Where the latter seems to be HTTP specific, and a chosen plain text attack. So all I'm suggesting is to be careful, and do appropriate comparisions, to see if one can ensure enabling compression does not enable an attack mode similar to those seen with TLS. Since I'm not sure if the lack of attacks against ESP+IPCOMP is due to inherent robustness, or simply a lack of trying. DF From nobody Thu Mar 10 12:55:33 2016 Return-Path: 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 41ED612DD68 for ; Thu, 10 Mar 2016 12:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-hipsec@employees.org header.d=employees.org 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 qZLZCHTN47T3 for ; Thu, 10 Mar 2016 12:55:32 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9567512DD67 for ; Thu, 10 Mar 2016 12:55:21 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 43FA2D7894; Thu, 10 Mar 2016 12:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=z+SHmcAGp5YjBOezCBK47UE3P6M=; b=lh VR6N6GK7kMkkNjot14DW1vN7MSS62xfLu4VgT5yqd4m304yae8+wWc/J3hSpqFg9 ljBVUarLz/hv3T1npy3VqVec+4efnXAcWLLtWm1enAEui6F8kkH84r26qPzjp51l V9ZdZRvtdQ0geOmmCZDof5bSbPuL0ebmS8q0Ceg8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=WvdzB16WDmwsdAA4slaE6nA/AHjN Wow5dIuvqAjhQLE2TuwLn7ljmCu6aB4KnwfL3dR6Q7ezS43Zwk5Ggjzb8bQGcSSR qBx6FRcNLXPj1jAYs470sOO9biuWIWPya50Vrf287gg+IgJ6bw2dumpp2dEU92Ef roLaiK8LW7z1g5o= Received: by cowbell.employees.org (Postfix, from userid 1736) id 357B0D7893; Thu, 10 Mar 2016 12:55:21 -0800 (PST) Date: Thu, 10 Mar 2016 20:55:21 +0000 From: Derek Fawcus To: Robert Moskowitz Message-ID: <20160310205521.GB39508@cowbell.employees.org> Mail-Followup-To: Robert Moskowitz , hipsec@ietf.org References: <56E03F56.5040300@htt-consult.com> <56E176AB.5070709@htt-consult.com> <20160310191041.GA14546@cowbell.employees.org> <56E1D565.5060605@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E1D565.5060605@htt-consult.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: hipsec@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 20:55:33 -0000 On Thu, Mar 10, 2016 at 03:13:25pm -0500, Robert Moskowitz wrote: > I have looked at both the CRIME and BREACH attacks and neither would > work against IPCOMP within ESP. Ah, good. > It DOES change some of my thoughts about compression as a XML option for > use in DOTS. That is pretty much what CRIME is attacking. So my spanner wasn't totally worthless :-) DF From nobody Mon Mar 21 12:04:37 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C73F12DAA0; Mon, 21 Mar 2016 12:04:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321190433.12211.62990.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 12:04:33 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 19:04:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Filename : draft-ietf-hip-dex-01.txt Pages : 47 Date : 2016-03-21 Abstract: This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to HIPv2. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-dex-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 12:18:29 2016 Return-Path: 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 2DD8112D9F0 for ; Mon, 21 Mar 2016 12:18:28 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 kEm4GLTVequv for ; Mon, 21 Mar 2016 12:18:14 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FDD612DA3D for ; Mon, 21 Mar 2016 12:18:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 15D51621DE for ; Mon, 21 Mar 2016 15:18:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fo4n7b-P7lVg for ; Mon, 21 Mar 2016 15:18:07 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C0119621DC for ; Mon, 21 Mar 2016 15:18:05 -0400 (EDT) To: hipsec@ietf.org References: <20160321190433.12211.62990.idtracker@ietfa.amsl.com> From: Robert Moskowitz Message-ID: <56F048E9.6050600@htt-consult.com> Date: Mon, 21 Mar 2016 15:18:01 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160321190433.12211.62990.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-dex-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 19:18:28 -0000 The 'only' change in this version is adding the new ECC from RFC 7748 the new Curve29919 and Curve448. PLEASE I know that our chair has set a long timeframe for getting this draft to last call, but. It is referenced in IEEE 802.15.9 that has gone through all the approvals. If this is not assigned an RFC number soon, the IEEE SA editors will cut HIP DEX from 802.15.9. And that also impacts how HIP-BEX is specified as DEX adds the ENCRYPT-KEY parameter needed by 15.9. So, for anyone that will be at IETF, let's set a time/place to get together and go through this so we can move it forward. I had worked for a year for an AD submission with lots of assurances that it would work, but in the end the ADs punted. So if you want to see HIP in other work, please review this and let's move it forward. On 03/21/2016 03:04 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol of the IETF. > > Title : HIP Diet EXchange (DEX) > Authors : Robert Moskowitz > Rene Hummen > Filename : draft-ietf-hip-dex-01.txt > Pages : 47 > Date : 2016-03-21 ..... From nobody Mon Mar 21 12:27:06 2016 Return-Path: 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 0220412DA81 for ; Mon, 21 Mar 2016 12:27:05 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 h-a0KtAY18eQ for ; Mon, 21 Mar 2016 12:27:03 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A1812DA73 for ; Mon, 21 Mar 2016 12:27:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 00EAF62187 for ; Mon, 21 Mar 2016 15:27:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AtG9MM7jKcv4 for ; Mon, 21 Mar 2016 15:27:00 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 4F3926218F for ; Mon, 21 Mar 2016 15:27:00 -0400 (EDT) To: hipsec@ietf.org From: Robert Moskowitz Message-ID: <56F04B02.60607@htt-consult.com> Date: Mon, 21 Mar 2016 15:26:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Hipsec] HIP in a new Session Layer Service 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 19:27:05 -0000 I invite you all to look at work Sue Hares, I, and a few others have been doing in developing a Session Layer Service that includes security at the session layer. FOr IETF reasons, Sue did the top-level draft within I2NSF: https://www.ietf.org/internet-drafts/draft-hares-i2nsf-ssls-00.txt Also see: https://www.ietf.org/internet-drafts/draft-moskowitz-dots-ssls-02.txt And it is kind of implied in the pub process in: https://www.ietf.org/internet-drafts/draft-moskowitz-firstmile-00.txt Important to ssls itself are two of its services in separate drafts: https://www.ietf.org/internet-drafts/draft-moskowitz-sse-03.txt https://www.ietf.org/internet-drafts/draft-moskowitz-gpcomp-00.txt Please look these over. I already have a time slot in DOTS for the dots-ssls, and Sue and I have one in I2NSF. I have applied for a slot in MILE, but have not heard back (but it may be covered in I2NSF). Help on the HIP portion, or any part of these drafts is appreciated. Oh, and Tero I know you are here on this list. I request your help on the IKE portions.... ;)' From nobody Mon Mar 21 13:36:31 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 434D712D5B4; Mon, 21 Mar 2016 13:36:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 13:36:27 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:36:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Filename : draft-ietf-hip-dex-02.txt Pages : 47 Date : 2016-03-21 Abstract: This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to HIPv2. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-dex-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 13:40:17 2016 Return-Path: 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 75F7A12DB5C; Mon, 21 Mar 2016 13:40:15 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 KDP90D0kIJie; Mon, 21 Mar 2016 13:40:14 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024DB12DB2D; Mon, 21 Mar 2016 13:40:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id C8F6F6218F; Mon, 21 Mar 2016 16:40:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kviCsy2FllT9; Mon, 21 Mar 2016 16:40:08 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C893A62111; Mon, 21 Mar 2016 16:40:07 -0400 (EDT) To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> From: Robert Moskowitz Message-ID: <56F05C25.7060303@htt-consult.com> Date: Mon, 21 Mar 2016 16:40:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-dex-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:40:15 -0000 Rene's new address! For those of you that did not notice this, he got a job! Actually been at it for a while... On 03/21/2016 04:36 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol of the IETF. > > Title : HIP Diet EXchange (DEX) > Authors : Robert Moskowitz > Rene Hummen > Filename : draft-ietf-hip-dex-02.txt > Pages : 47 > Date : 2016-03-21 > > Abstract: > This document specifies the Host Identity Protocol Diet EXchange (HIP > DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The > HIP DEX protocol design aims at reducing the overhead of the employed > cryptographic primitives by omitting public-key signatures and hash > functions. In doing so, the main goal is to still deliver similar > security properties to HIPv2. > > The HIP DEX protocol is primarily designed for computation or memory- > constrained sensor/actuator devices. Like HIPv2, it is expected to > be used together with a suitable security protocol such as the > Encapsulated Security Payload (ESP) for the protection of upper layer > protocol data. In addition, HIP DEX can also be used as a keying > mechanism for security primitives at the MAC layer, e.g., for IEEE > 802.15.4 networks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-hip-dex-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Fri Mar 25 15:49:25 2016 Return-Path: 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 04DBD12D19B for ; Fri, 25 Mar 2016 15:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-hipsec@employees.org header.d=employees.org 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 U3uu_vcPB8OB for ; Fri, 25 Mar 2016 15:49:22 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442BB12D0AD for ; Fri, 25 Mar 2016 15:49:22 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id AED97D7893 for ; Fri, 25 Mar 2016 15:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:subject:message-id:mime-version:content-type; s=selector1; bh=aWMnOrY9LSMwlJuw1CGgmFZFkBQ=; b=S7M70eHyjSAutfTjFv0PHvkKlwln MsJXXVWEsvRka+FCOS21mIRJ5k0nZToqhzcDl98QL2vNKb35e6HXMVPljNhjo7kv c7CsKpV+DOp8BHbYP3pJ/A4jYjvdJhfly1l/4/W3m5VgFzadIusjP20IZ4ybxjS+ 4oqiFRcscQtuwYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:subject:message-id:mime-version:content-type; q=dns; s= selector1; b=AxI/Q8UCCtLCYrA/oWMdtV7s+vozz9udMwA2NkLFAFdxEW3qFXk e7O1lFP8IGDyA021mc+gsgREy+jmYk4chgRcZv340Yls0hwQfqZqXRnwz8HPiAx0 htt9qGBy16aTciAmazeajW2f8GkcFzjbvr/srotpODwtrehrErun3Elk= Received: by cowbell.employees.org (Postfix, from userid 1736) id A1405D7884; Fri, 25 Mar 2016 15:49:21 -0700 (PDT) Date: Fri, 25 Mar 2016 23:49:21 +0100 From: Derek Fawcus To: hipsec@ietf.org Message-ID: <20160325224921.GA75376@cowbell.employees.org> Mail-Followup-To: hipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Hipsec] Segmentation within 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 22:49:24 -0000 Recently I've been working on middlebox s/w: Firewalls and NAT. One thing this has brought home to me is just how unreliable fragmentation is on the current Internet. NAT will often simply break it (such that they can not be reassembled) or just discard them, and firewalls are often set up to block them. As such, almost every protocol now would seem to need protocol level segmentation/fragmentation, rather than depend up IP level fragmentation. It struck me that it should be quite simple to extend HIP to support such. 1) Add a Controls bit which advertises that the sender supports segmentation. 2) Define a new parameter, numbered 1 such that it is first in the parameters, and is critical. Within the parameter have a seqno/identifier, offset and more segments / final segment bit, possibly also a total size field. Define some simple reassembly rules, similar to those for IP fragments, such that one could reassemble a HIP packet larger than 2008 bytes if desired (how big?). 3) Possibly also define a none critical parameter within the non signed, non MACed range which advertises the max size packet the sender is willing to reassemble. In fact I guess this might remove the need to use a Controls bit, since it would imply the sender can reassemble. Then have a rule that once one party has seen the other party advertise the segmentation capability within the current BEX session, it is free to make use of segmentation towards that peer. Thoughts? DF From nobody Fri Mar 25 18:20:09 2016 Return-Path: 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 513E012D0C5 for ; Fri, 25 Mar 2016 18:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pZ8XmTTW7TzS for ; Fri, 25 Mar 2016 18:20:07 -0700 (PDT) Received: from mxout22.s.uw.edu (mxout22.s.uw.edu [128.95.242.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072ED12D09C for ; Fri, 25 Mar 2016 18:20:06 -0700 (PDT) Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout22.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u2Q1GTuM020090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2016 18:16:30 -0700 Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u2Q1GSKR023378; Fri, 25 Mar 2016 18:16:28 -0700 Received: from localhost (Unknown UID 10745@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u2Q1GQio023346; Fri, 25 Mar 2016 18:16:28 -0700 X-Auth-Received: from [73.239.169.224] by hymn04.u.washington.edu via HTTP; Fri, 25 Mar 2016 18:16:26 PDT Date: Fri, 25 Mar 2016 18:16:26 -0700 (PDT) From: Tom Henderson To: dfawcus+lists-hipsec@employees.org Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.26.11217 X-PMX-Server: mxout22.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Segmentation within 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 01:20:08 -0000 On 03/25/2016 03:49 PM, Derek Fawcus wrote: > Recently I've been working on middlebox s/w: Firewalls and NAT. > > One thing this has brought home to me is just how unreliable > fragmentation is on the current Internet. NAT will often > simply break it (such that they can not be reassembled) or > just discard them, and firewalls are often set up to block them. > > As such, almost every protocol now would seem to need protocol > level segmentation/fragmentation, rather than depend up IP > level fragmentation. > > It struck me that it should be quite simple to extend HIP to > support such. > > 1) Add a Controls bit which advertises that the sender supports > segmentation. > 2) Define a new parameter, numbered 1 such that it is first in > the parameters, and is critical. > Within the parameter have a seqno/identifier, offset and > more segments / final segment bit, possibly also a total > size field. Define some simple reassembly rules, similar > to those for IP fragments, such that one could reassemble > a HIP packet larger than 2008 bytes if desired (how big?). > 3) Possibly also define a none critical parameter within the > non signed, non MACed range which advertises the max size > packet the sender is willing to reassemble. In fact I guess > this might remove the need to use a Controls bit, since it > would imply the sender can reassemble. > > Then have a rule that once one party has seen the other party > advertise the segmentation capability within the current BEX > session, it is free to make use of segmentation towards that peer. > > Thoughts? > > DF Hi Derek, I don't remember the details, but in the early days of HIP, it was decided to avoid the burden of supporting fragmentation. I guess I'd prefer to see some evidence that HIP messages are being fragmented in the wild before starting a work effort to add support. - Tom From nobody Mon Mar 28 13:05:46 2016 Return-Path: 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 B317412DB7D for ; Mon, 28 Mar 2016 13:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 UTHCCbS1YcwF for ; Mon, 28 Mar 2016 13:05:40 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C0F12DB70 for ; Mon, 28 Mar 2016 13:05:39 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-22-56f98e9180c2 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id ED.D3.22880.19E89F65; Mon, 28 Mar 2016 22:05:37 +0200 (CEST) Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.248.2; Mon, 28 Mar 2016 22:05:36 +0200 To: References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> From: Miika Komu Organization: Ericsson AB Message-ID: <56F98E90.10601@ericsson.com> Date: Mon, 28 Mar 2016 23:05:36 +0300 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: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030407040506000103060406" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM2K7q+7Evp9hBh0XzCymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDuzbAsO/WCsWHLyNksD45sTjF2MnBwSAiYS85r+M0HYYhIX 7q1n62Lk4hASOMIocartJSuEs5pR4tOeLWwgVcICehIzr7ezgNgiAqISUz6cZgaxhQQcJVbe +gA2lU1AS2LVnetgcX4BSYkNDbvBbF4BTYmOnz9YQWwWAVWJj1OXgG0WFYiQeDL3JCNEjaDE yZlPwOZzCjhJ3Fy0kgXkCGaBbkaJa4uXsncxcgAtU5G4eCx4AqPALCQts5CVgSSYBWwl7szd zQxha0ssW/gayraWmPHrIBuErSgxpfshVL2pxOujHxkhbGOJZev+si1g5FjFKFqcWlycm25k rJdalJlcXJyfp5eXWrKJERgBB7f81t3BuPq14yFGAQ5GJR7eB+E/woRYE8uKK3MPMaoAzXm0 YfUFRimWvPy8VCURXvfen2FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEedk+XQ4TEkhPLEnNTk0t SC2CyTJxcEo1MIoaVG3pfpezuqXh7zQO222B23ib/jidP5obnTg3eHmG66Vnhz3OGO/mCDZc Gfy8p8tHN0I0cO1nY8vkp328+icqHtxJWLhY2X67taaut19yz8lVVlqny3d2LdjKeX5PlUXt 4RXL9vlPX73V64yj7anFfVaXXDUK2L2kz+VymLMfe7VN6YiMvRJLcUaioRZzUXEiAHmYrwyI AgAA Archived-At: Subject: [Hipsec] A review of draft-ietf-hip-dex-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 20:05:44 -0000 --------------ms030407040506000103060406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, > 1.1. The HIP Diet EXchange (DEX) > Data packets start to flow after the 4th packet. The 3rd and 4th HIP > packets may carry data payload in the future. However, the details > of this may be defined later. Similarly as in RFC7401, data packets start to flow... (I guess you could also mention RFC6078 as another further work item) > An existing HIP association can be updated with the update mechanism > defined in [RFC7401]. Likewise, the association can be torn down > with the defined closing mechanism for HIPv2 if it is no longer > needed. HIP DEX thereby omits the HIP_SIGNATURE parameters of the > original HIPv2 specification. Why "thereby"? I don't see the connection. > HIP DEX does not have the option to encrypt the Host Identity of the > Initiator in the 3rd packet. The Responder's Host Identity also is > not protected. Thus, contrary to HIPv2, there is no attempt at > anonymity. The anonymous bit still exists, so I suggest changing the wording: there is no attempt at anonymity -> such Responder anonymity is not=20 preserved in HIP DEX. > 2.1. Requirements Terminology In section 6.3, you are introduce also -> notation, which was not explained. > 2.3. Definitions I suggest to add also the definitions of both MAC and CMAC because they are used throughout the document. They are also used in this section. > 3.1. Host Identity Tag (HIT) Just thinking aloud... should a DEX HIT have a different context ID? Probably not. > 4.1. Creating a HIP Association > The HIP Diet EXchange serves to manage the establishment of state > between an Initiator and a Responder. The first packet, I1, > initiates the exchange, and the last three packets, R1, I2, and R2, > constitute an authenticated Diffie-Hellman [DH76] key exchange for > the Master Key SA generation. This Master Key SA is used by the > Initiator and the Responder to wrap secret keying material in the I2 > and R2 packets. Based on the exchanged keying material, the peers > then derive a Pair-wise Key SA if cryptographic keys are needed, > e.g., for ESP-based protection of user data. (Suggest replacing "user data" with e.g. "data plane" in the entire document since you're talking about machines (sensors) that may not have a user) > In the I2 packet, the Initiator MUST display the solution to the > received puzzle. Without a correct solution, the I2 packet is > discarded. The I2 also contains a key wrap parameter that carries a > secret keying material of the Initiator. This keying material is > only half the final session key. The packet is authenticated by the > sender (Initiator) via a MAC. =2E..half *of* the... > The R2 packet acknowledges the receipt of the I2 packet and completes > the handshake. The R2 contains a key wrap parameter that carries the > rest of the keying material of the Responder. The packet is > authenticated by the sender (Responder) via a MAC. key wrap parameter -> parameter with encrypted contents > 4.1.1. HIP Puzzle Mechanism > > The puzzle mechanism enables a Responder to immediately reject an I2 > packet if it does not contain a valid puzzle solution. To verify the > puzzle solution, the Responder only has to compute a single CMAC > operation. After a successful puzzle verification, the Responder can > securely create session-specific state and perform CPU-intensive > operations such as a Diffie-Hellman key generation. By varying the > difficulty of the puzzle, the Responder can frustrate CPU or memory > targeted DoS attacks. =2E..can frustrate *an Initiator*... > Conceptually, the puzzle mechanism in HIP DEX is the same as in > HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in > [RFC7401] for more detailed information about the employed mechanism. > Notably, the only difference between the puzzle mechanism in HIP DEX > and HIPv2 is that HIP DEX uses CMAC instead of a hash function for > solving and verifying a puzzle. The implications of this change on > the puzzle implementation are discussed in Section 6.1. The other difference is mentioned in section 6.1: "The only exceptions are that HIP DEX does not use pre-computation of R1 packets and that RHASH is set to CMAC. As a result, the pre- computation step in in Section 6.3 of [RFC7401] is skipped in HIP DEX." > 4.1.2.1. HIP DEX Retransmission Mechanism > The potentially high processing time of an I2 packet at a (resource- > constrained) Responder may cause premature retransmissions if the > time required for I2 transmission and processing exceeds the RTT- > based retransmission timeout. Thus, the Initiator should also take > the processing time of the I2 packet at the Responder into account > for retransmission purposes. To this end, the Responder MAY notify > the Initiator about the anticipated delay once the puzzle solution > was successfully verified and if the remaining I2 packet processing > incurs a high processing delay. The Responder MAY therefore send a > NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator > before the Responder commences the ECDH operation. The NOTIFY packet > serves as an acknowledgement for the I2 packet and consists of a > NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT > (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter > contains the anticipated remaining processing time for the I2 packet > in milliseconds as two-octet Notification Data. This processing time > can, e.g., be estimated by measuring the computation time of the ECDH > key derivation operation at Responder boot-up. After the I2 > processing has finished, the Responder sends the regular R2 packet. ( boot-up -> start-up procedures (it doesn't have to be a boot) ) > 4.1.2.3. Simplified HIP State Diagram > The following diagram shows the major state transitions. Transitions > based on received packets implicitly assume that the packets are > successfully authenticated or processed. Is the new NOTIFY illustrated also in the figure? > 5.2.1. DH_GROUP_LIST > > The DH_GROUP_LIST parameter contains the list of supported DH Group > IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With > HIP DEX, the DH Group IDs are restricted to: > > Group KDF Value > > NIST P-256 [RFC5903] CKDF 7 > NIST P-384 [RFC5903] CKDF 8 > NIST P-521 [RFC5903] CKDF 9 > SECP160R1 [SECG] CKDF 10 > Curve25519 [RFC7748] CKDF 11 > Curve448 [RFC7748] CKDF 12 > > The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH > group 10 is covered in [SECG] and Appendix D of [RFC7401]. These > curves, when used with HIP MUST have a co-factor of 1. I suggest to change the "value" column title to "group id" or change the = text as follows: "The ECDH groups with *values* 7 - 9..." > The ECDH groups 11 and 12 are defined in [RFC7748]. These curves > have cofactors of 8 and 4 (respectively). Same comment as previously. > 5.2.3. HOST_ID > > The HOST_ID parameter conveys the Host Identity (HI) along with > optional information about a host. It is defined in Section 5.2.9 of > [RFC7401]. > > HIP DEX uses the public portion of a host's static ECDH key-pair as > the HI. Correspondingly, HIP DEX limits the HI algorithms to the > following profile: I would add "*new* profile" since this is not part of RFC7401. > 5.2.4. HIT_SUITE_LIST > > The HIT_SUITE_LIST parameter contains a list of the supported HIT > suite IDs of the Responder. Based on the HIT_SUITE_LIST, the > Initiator can determine which source HIT Suite IDs are supported by > the Responder. The HIT_SUITE_LIST parameter is defined in > Section 5.2.10 of [RFC7401]. > The following HIT Suite IDs are defined for HIP DEX, and the > relationship between the four-bit ID value used in the OGA ID field > and the eight-bit encoding within the HIT_SUITE_LIST ID field is > clarified: =2E..the following *new* HIT Suite IDs... =2E..is clarified: -> ...is defined as follows: > Note that the HIP DEX HIT Suite ID allows the peers to distinguish a > HIP DEX handshake from a HIPv2 handshake. The Responder MUST respond > with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP > DEX HIT. The details are a bit unclear. Which packet are you talking about here? I mean the suite id is in R1 (and not in I1), so I guess you're=20 referring that Responder must respond to I2 with an R2 that contains HIP DEX HITs? In general, I'd urge the authors to write a separate "Compatibility with HIP base exchange" section in the end of the document with the two (problematic) use cases: 1. Initiator=3DDEX, Responder=3DBEX 2. Initiator=3DBEX, Responder=3DDEX How what happens in each case? Can the Initiator still try to communicate (in case the Responder could potentially support both protocols) or should it just abort? When exactly each party knows and from which parameters both of the parties detect incompatibilities? Consider also the opportunistic mode. Bits and pieces of this discussion was scattered here and there, but it would useful to recap this is one single section due to compatibility issues with RFC7401. > 5.2.5. ENCRYPTED_KEY > > [...] > > The ENCRYPTED_KEY parameter encapsulates a random value that is later > used in the session key creation process (see Section 6.3). This > random value MUST have a length of at least 64 bit. The puzzle value > #I and the puzzle solution #J (see [RFC7401]) are used as the > initialization vector (IV) for the encryption process. To this end, > the IV is computed as FOLD(I | J, 128). The AES-CTR counter is a 16 > bit value that is initialized to zero with the first use. The initialization vector is a explicit, separate field in RFC7401. Why=20 I and J are implicitly reused here? To save bits? The AES-CTR counter pops out a bit suddenly here. Perhaps you could "bridge" it to the text in a bit more smoother way. > Once this encryption process is completed, the "encrypted value" data > field is ready for inclusion in the Parameter. If necessary, > additional Padding for 8-byte alignment is then added according to > the rules of TLV Format in [RFC7401]. The key could be also included in ENCRYPTED parameter, which can accommodate multiple parameters... unless it is very important to keep the IV implicit. > 5.3. HIP Packets > > [...] > > In the future, an optional upper-layer payload MAY follow the HIP > header. The Next Header field in the header indicates if there is > additional data following the HIP header. RFC6078 is also future work. > 5.3.1. I1 - the HIP Initiator Packet > > [...] > > As a compression of the employed HIs, the Initiator's and the > Responder's HITs both determine the DH group ID that must be used in > order to successfully conclude the triggered handshake. HITs, > however, only include the OGA ID identifying a HIP DEX HIT. They do > not include information about the specific DH group ID of the > corresponding HI. [...] Something wrong here, the first sentence is contradicting with the second and third one. > 5.3.2. R1 - the HIP Responder Packet > > [...] > > The R1 packet generation counter is used to determine the currently > valid generation of puzzles. The value is increased periodically, > and it is RECOMMENDED that it is increased at least as often as > solutions to old puzzles are no longer accepted. Section 6.1 describes: "The only exceptions are that HIP DEX does not use pre-computation of R1 packets and that RHASH is set to CMAC. As a result, the pre- computation step in in Section 6.3 of [RFC7401] is skipped in HIP DEX. I guess R1 packet generation counters are still meaningful for the Initiator (despite Responder does not pre-generate R1s)? > [...] > > The HOST_ID parameter depends on the received DH_GROUP_LIST parameter > and the Responder HIT in the I1 packet. Specifically, if the I1 > contains a Responder HIT, the Responder verifies that this HIT > matches the required DH group based on the received DH_GROUP_LIST > parameter. "...included in the I1". Right? > 5.3.3. I2 - the Second HIP Initiator Packet > > [...] > > The HIP_CIPHER contains the single encryption transform selected by > the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY > parameters. The chosen cipher MUST correspond to one of the ciphers > offered by the Responder in the R1. All implementations MUST support > the AES-CTR transform [RFC3686]. > > [...] > > The TRANSPORT_FORMAT_LIST parameter contains the single transport > format type selected by the Initiator. The chosen type MUST > correspond to one of the types offered by the Responder in the R1 > packet. Currently, the only transport format defined is the ESP > transport format [RFC7402]. Should all of the cipher suites and transport formats still be echoed to the Responder for security reasons? See also my next comment. > 5.3.4. R2 - the Second HIP Responder Packet > > [...] > > The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, > and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These > parameters MUST be the same as included in the R1 packet. The > parameter are re-included here because the R2 packet is MACed and > thus cannot be altered by an attacker. For verification purposes, > the Initiator re-evaluates the selected suites and compares the > results against the chosen ones. If the re-evaluated suites do not > match the chosen ones, the Initiator acts based on its local policy. Ok, so now the full list of parameters is included, so forget about my previous comment. > 6.1. Solving the Puzzle > > The procedures for solving and verifying a puzzle in HIP DEX are > strongly based on the corresponding procedures in HIPv2. The only > exceptions are that HIP DEX does not use pre-computation of R1 > packets and that RHASH is set to CMAC. As a result, the pre- > computation step in in Section 6.3 of [RFC7401] is skipped in HIP > DEX. in in -> in > 6.2.1. CMAC Calculation > > [...] > > > 5. Set Checksum and Header Length fields in the HIP header to > original values. Note that the Checksum and Length fields > contain incorrect values after this step. I guess also the values following HIP_MAC should be restored since they were wiped in the step 2. > 6.3. HIP DEX KEYMAT Generation (this section was a bit hard to understand) > The HIP DEX KEYMAT process is used to derive the keys for the Master > Key SA as well as for the Pair-wise Key SA. The keys for the Master > Key SA are based from the Diffie-Hellman derived key, Kij, produced from -> on > The keys of the Pair-wise Key SA are not directly used in the HIP DEX > handshake. [...] used -> exposed in plaintext? > Some payload protection mechanisms have their own > Key Derivation Function, and if so this mechanism SHOULD be used. this -> such > The HIP DEX KEYMAT process consists of two components, CKDF-Extract > and CKDF-Expand. The Extract function compresses a non-uniformly > distributed key, as is the output of a Diffie-Hellman key derivation, as is -> such as > The key derivation for the Master Key SA employs both the Extract and > Expand phases, whereas the Pair-wise Key SA MAY need both the Extract > and Expand phases if the key is longer than 128 bits. Otherwise, it > only requires the Expand phase. Suggest: The key derivation for the Master Key SA employs always both the Extract and Expand phases. The Pair-wise Key SA needs only the Extract phase when key is smaller or equal to 128 bits, but otherwise requires also the Expand phase. > The CKDF-Extract function is the following operation: > > CKDF-Extract(I, IKM, info) -> PRK What does the arrow operator signify? I thought that it produces PRK, but PRK is actually defined below. > where > > I Random #I from the PUZZLE parameter > IKM Input keying material, i.e., either the Diffie-Hellman > derived key or the concatenation of the random values > of the ENCRYPTED_KEY parameters in the same order as > the HITs with sort(HIT-I | HIT-R) So how to choose between the D-H key and ENCRYPTED_KEY? Use always the KEY if present, otherwise D-H? > info sort(HIT-I | HIT-R) | "CKDF-Extract" Is "CKDF-Extract" an octet string? > PRK a pseudorandom key (of RHASH_len/8 octets) > | denotes the concatenation > > The pseudorandom key PRK is calculated as follows: > > PRK =3D CMAC(I, IKM | info) Based on this, I don't really know how to extract key material (the arrow notation is confusing). > The CKDF-Expand function is the following operation: > > CKDF-Expand(PRK, info, L) -> OKM What does the arrow mean? Maybe name "info" as "info2" because it is different variable. > where > > PRK a pseudorandom key of at least RHASH_len/8 octets > (either the output from the extract step or the > concatenation of the random values of the > ENCRYPTED_KEY parameters in the same order as the > HITs with sort(HIT-I | HIT-R)) How to choose between the extract output vs encrypted key? Maybe you should rename this as "PRK2" in order to distinguish the variable from the Extract phase. > info sort(HIT-I | HIT-R) | "CKDF-Expand" Is "CKDF-Expand" an octet string? > L length of output keying material in octets > (<=3D 255*RHASH_len/8) > | denotes the concatenation > > The output keying material OKM is calculated as follows: > > N =3D ceil(L/RHASH_len/8) > T =3D T(1) | T(2) | T(3) | ... | T(N) > OKM =3D first L octets of T > > where > > T(0) =3D empty string (zero length) > T(1) =3D CMAC(PRK, T(0) | info | 0x01) > T(2) =3D CMAC(PRK, T(1) | info | 0x02) > T(3) =3D CMAC(PRK, T(2) | info | 0x03) > ... The Expand was a bit more clear, but still didn't understand how to get=20 to the Expanded key material due the arrow notation. > (where the constant concatenated to the end of each T(n) is a > single octet.) Is there a max value? > The initial keys are drawn sequentially in the order that is > determined by the numeric comparison of the two HITs, with the > comparison method described in the previous paragraph. HOST_g > denotes the host with the greater HIT value, and HOST_l the host with > the lower HIT value. This is just for Master keys, right? > The number of bits drawn for a given algorithm is the "natural" size > of the keys. For the mandatory algorithms, the following sizes > apply: > > AES 128 or 256 bits I would clarify that this depends on the negotiated HIP_CIPHER. > 6.5. Processing Incoming I1 Packets > > 5. If the received Responder's HIT in the I1 packet is not NULL, the > Responder's in the R1 packet HIT MUST match the destination HIT =2E..the Responder's HIT in the R1 packet MUST match... > 6.6. Processing Incoming R1 Packets > > [...] > > 1. A system receiving an R1 MUST first check to see if it has sent > an I1 packet to the originator of the R1 packet (i.e., it has a > HIP association that is in state I1-SENT and that is associated > with the HITs in the R1). Unless the I1 packet was sent in > opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP > addresses in the received R1 packet SHOULD be ignored by the R1 > processing and, when looking up the right HIP association, the right -> correct > 8. The R1 packet may have the A-bit set - in this case, the system > MAY choose to refuse it by dropping the R1 packet and returning > to state UNASSOCIATED. The system SHOULD consider dropping the > R1 packet only if it used a NULL HIT in the I1 packet. I didn't understand the logic in the last sentence. > Note that step 4 from the original processing rules of HIPv2 > (signature verification) has been removed in the above processing > rules for HIP DEX. Moreover, step 7 of the HIPv2 processing rules > has been adapted to account for the fact that HIP DEX uses ECDH > public keys as HIs. Step 7 in the *original* processing rules, what is the ordinal in DEX? It is not 7. > 6.7. Processing Incoming I2 Packets > > [...] > > 5. If the system's state machine is in the I2-SENT state, the > system MUST make a comparison between its local and sender's > HITs (similarly as in Section 6.3). If the local HIT is smaller > than the sender's HIT, it should drop the I2 packet, use the > peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce > #I from the R1 packet received earlier, and get the local > Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J > from the I2 packet sent to the peer earlier. Otherwise, the > system should process the received I2 packet and drop any > previously derived Diffie-Hellman keying material Kij and > ENCRYPTED_KEY keying material it might have generated upon > sending the I2 packet previously. The peer Diffie-Hellman key, > ENCRYPTED_KEY, and the nonce #J are taken from the just arrived > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying > material, and the nonce #I are the ones that were sent earlier > in the R1 packet. Please replace "sender" with "peer" (or remote host) in this section for more symmetric terminology. get -> obtain > 11. The implementation SHOULD also verify that the Initiator's HIT > in the I2 packet corresponds to the Host Identity sent in the I2 > packet. (Note: some middleboxes may not be able to make this > verification.) Why SHOULD? Why not MUST? I think we're talking about end-hosts here anyway. > Note that steps 11 (encrypted HOST_ID) and 15 (signature > verification) from the original processing rules of HIPv2 have been > removed in the above processing rules for HIP DEX. Moreover, step 10 > of the HIPv2 processing rules has been adapted to account for > optional extension of the retransmission mechanism. Step 16 has been > added to the processing rules. =2E..in this document. > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets > UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]). > The only difference is the that the HIP_SIGNATURE is never present > and, therefore, is not required to be processed by the receiving > party. How does rekeying work with the extract and expand functions? > 6.11. Handling State Loss > Implementors MAY choose to use non-volatile, secure storage for HIP > states in order for them to survive a system reboot. If no secure > storage capabilities are available, the system SHOULD delete the > corresponding HIP state, including the keying material. If the > implementation does drop the state (as RECOMMENDED), it MUST also > drop the peer's R1 generation counter value, unless a local policy > explicitly defines that the value of that particular host is stored. > An implementation MUST NOT store a peer's R1 generation counters by > default, but storing R1 generation counter values, if done, MUST be > configured by explicit HITs. MUST NOT -> SHOULD? Otherwise the part after this is kinda void. > 7. HIP Policies > There are a number of variables that will influence the HIP exchanges > that each host must support. All HIP DEX implementations SHOULD > provide for an ACL of Initiator's HI to Responder's HI. This ACL > SHOULD also include preferred transform and local lifetimes. > Wildcards SHOULD also be supported for this ACL. Why ACLs are mandatory? ACL -> ACL consisting of > The value of #K used in the HIP R1 must be chosen with care. Values > of #K that are too high will exclude clients with weak CPUs because > these devices cannot solve the puzzle within a reasonable amount of > time. #K should only be raised if a Responder is under high load, > i.e., it cannot process all incoming HIP handshakes any more. If a > Responder is not under high load, #K SHOULD be 0. > 8. Security Considerations > o The HIP DEX HIT generation may present new attack opportunities. They cannot be used in ACLs. Maybe this could be mentioned. Can this be mitigated by always using full HIs? Some additional comments related to Appendix: I think you could reference the SLIMFIT extension from Rene Hummen in the appendix. And possibly mention the following related work extending DEX that was done in the context of Convince Celtic+ project: P. Porambage, A. Braeken, P. Kumar, A. Gurtov and M. Ylianttila, "Efficient Key Establishment for Constrained IoT Devices with Collaborative HIP-Based Approach," 2015 IEEE Global Communications Conference (GLOBECOM), San Diego, CA, 2015, pp. 1-6. doi: 10.1109/GLOCOM.2015.7417094 The work includes also benchmarks on energy consumption. P.S. My review can be credited to Convince Celtic+. --------------ms030407040506000103060406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzI4MjAwNTM2 WjAvBgkqhkiG9w0BCQQxIgQgYd0jrukkKW5qjOg4Ro4HJGzkJnANrXyK9YfJdguV3FYwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBCSLK6OUBR 52/HOIqvifhqBhF2b+YE2MupzaWwAMtgl0DX7NnliGKobRy8AXMLHE7XEbBLc20zrmFy2Z1S kIFRC9iDxCRuZbxuS6YQz3QNRysxTwgTow1bznyFMKf1B2c9NxMOi3Q2ELoQaVRwzF+Z21Xg RFc+yO1FAkpJ2x5+REQIqOgqd3oAiHc1KvlOmPhJImArc++26iYQznN7spv23+eH2ejMaRuv M4/JN3LqFucdDv7dqzBupyBhgy6J+ciSLZ4m9JlyMI9w4qNVhNMxtlGLa+zw4nDUsjuDk6JK QLh5fbiiY548KgeaXMxPztYzr0wCj7zkM1Sqor6ucON/AAAAAAAA --------------ms030407040506000103060406-- From nobody Mon Mar 28 16:51:19 2016 Return-Path: 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 BE561127058 for ; Mon, 28 Mar 2016 16:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-hipsec@employees.org header.d=employees.org 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 UUaqhzq9omXP for ; Mon, 28 Mar 2016 16:51:16 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA4312D104 for ; Mon, 28 Mar 2016 16:51:07 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id E7F9DD7883; Mon, 28 Mar 2016 16:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=3VnY5PJBMi62ahxjS631E+xTyBM=; b=jc AUUows/bXbCeuemQ7NJo3mNLa6EY+NKTLxquev+eQzhn40/hoE066fcMBK4OyeqL W1r4SjIsaCa1bxI0I6VEcsH1biDyUhPUOaYJn1ALafvgj097geOmqT0MQw+Bqi3P s3LKEj/3sQt0otQ7ljueSv+RQtHtRVGh5so1KGOjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=jJzHRmv6qEBGd3pAw/K1GjvXo+9U 7e24sQkEzFHWGiwhQ1lAJ13tMukCo7pFoFj37i2OZN9A51UwDivxRUx5uePkWArR V7vwlIWkAbPUnij8GfvvnXUG3fYsJp+u2JdJGzfzyFJRzIMRe/M03Z3aeKeoIBJu hmVDn4R1Gm1EWVU= Received: by cowbell.employees.org (Postfix, from userid 1736) id DA8FAD7882; Mon, 28 Mar 2016 16:51:06 -0700 (PDT) Date: Tue, 29 Mar 2016 00:51:06 +0100 From: Derek Fawcus To: Gonzalo Camarillo Message-ID: <20160328235106.GA79648@cowbell.employees.org> Mail-Followup-To: Gonzalo Camarillo , Miika Komu , hipsec@ietf.org References: <56CDBDA1.7050207@ericsson.com> <3CEE85EA-C996-4B28-B0A3-DA8B158BD159@temperednetworks.com> <56D1630A.7000209@ericsson.com> <56D45895.2060503@ericsson.com> <56DD757B.8050002@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56DD757B.8050002@ericsson.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 23:51:17 -0000 On Mon, Mar 07, 2016 at 02:35:07pm +0200, Gonzalo Camarillo wrote: > First he will look into adding clarifications to the existing draft > while still referencing the old RFC. If the group is not happy with the > readability after the editorial pass (or our AD does not finally let us > downref the old RFC), we can consider bringing material from the old RFC > directly into the new one. Sorry, that I'm quite late in looking at these, but have been doing so recently... I have to say that I find the it difficult to decode simply because of having to refer to 3 (the draft, 5770, 5245) plus possibly the STUN/TURN docs at once. I'd certainly find it easier to comprehend if the text from 5770 was incorporated (suitably modified to account for not doing STUN/TURN) within the draft. That way the references to the significant pieces of 5245 text would be easier to nail down. As it is, I currently find it a bit like reading an Act of Parliament! e.g. $3.8 Connectivity Checks refers to $4.6 of 5770 with some exceptions, $4.6 of 5770 refers to $5.7 of 5245 and $7 of 5245, where the exceptions (use of UPDATE instead of STUN) have to be applied to that $7 referencing 5389, so possibly I don't have to read 5389, since hopefully it would just be packet formats. > I would also like the group to comment on the following two proposals: > > 1) the draft will allow implementers to use HIP native relays only. In > addition, the use of STUN and TURN relays will be optional. I'd suggest the draft be native only, but say with an appendix referencing 5770 for use of STUN/TURN, maybe indicating which bits of the 5770 to take heed of. > 2) in addition to covering the base exchange, the draft will also cover > the mobility readdressing exchange. Not having read that recently, I can't really comment. DF From nobody Mon Mar 28 17:46:23 2016 Return-Path: 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 07A0A12D0AC for ; Mon, 28 Mar 2016 17:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EUR0x8r6HBqE for ; Mon, 28 Mar 2016 17:46:19 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7FB12D1BA for ; Mon, 28 Mar 2016 17:46:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 23B7362250 for ; Mon, 28 Mar 2016 20:46:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zJPRyni1Hj35 for ; Mon, 28 Mar 2016 20:46:12 -0400 (EDT) Received: from lx120e.htt-consult.com (108.sub-70-199-4.myvzw.com [70.199.4.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A51586224F for ; Mon, 28 Mar 2016 20:46:11 -0400 (EDT) To: hipsec@ietf.org References: <20160325224921.GA75376@cowbell.employees.org> From: Robert Moskowitz Message-ID: <56F9D051.8010506@htt-consult.com> Date: Mon, 28 Mar 2016 20:46:09 -0400 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: <20160325224921.GA75376@cowbell.employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Hipsec] Segmentation within 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 00:46:22 -0000 Please see: draft-hares-i2nsf-ssls-00-02.txt Sue Hares and I are working on a whole session layer architecture where chunking and frag/reassem are parts of the session layer. The work we are doing there, definitely would easily apply to HIP. Actually you need more that a bit. Really 7 (this is what I did in IEEE 802.15.9), but 6 work. I would be interested in sitting down with you at IETF on this. This week I am busy with my youngest son's wedding (tomorrow night). On 03/25/2016 06:49 PM, Derek Fawcus wrote: > Recently I've been working on middlebox s/w: Firewalls and NAT. > > One thing this has brought home to me is just how unreliable > fragmentation is on the current Internet. NAT will often > simply break it (such that they can not be reassembled) or > just discard them, and firewalls are often set up to block them. > > As such, almost every protocol now would seem to need protocol > level segmentation/fragmentation, rather than depend up IP > level fragmentation. > > It struck me that it should be quite simple to extend HIP to > support such. > > 1) Add a Controls bit which advertises that the sender supports > segmentation. > 2) Define a new parameter, numbered 1 such that it is first in > the parameters, and is critical. > Within the parameter have a seqno/identifier, offset and > more segments / final segment bit, possibly also a total > size field. Define some simple reassembly rules, similar > to those for IP fragments, such that one could reassemble > a HIP packet larger than 2008 bytes if desired (how big?). > 3) Possibly also define a none critical parameter within the > non signed, non MACed range which advertises the max size > packet the sender is willing to reassemble. In fact I guess > this might remove the need to use a Controls bit, since it > would imply the sender can reassemble. > > Then have a rule that once one party has seen the other party > advertise the segmentation capability within the current BEX > session, it is free to make use of segmentation towards that peer. > > Thoughts? > > DF > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Mon Mar 28 17:47:16 2016 Return-Path: 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 9967E12D1DB for ; Mon, 28 Mar 2016 17:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 z5gILqVxDK2y for ; Mon, 28 Mar 2016 17:47:13 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F16112D195 for ; Mon, 28 Mar 2016 17:47:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3B4A662250; Mon, 28 Mar 2016 20:47:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wefBI1yT2eew; Mon, 28 Mar 2016 20:47:06 -0400 (EDT) Received: from lx120e.htt-consult.com (108.sub-70-199-4.myvzw.com [70.199.4.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 954246224F; Mon, 28 Mar 2016 20:47:04 -0400 (EDT) To: Tom Henderson , dfawcus+lists-hipsec@employees.org References: From: Robert Moskowitz Message-ID: <56F9D086.1000105@htt-consult.com> Date: Mon, 28 Mar 2016 20:47:02 -0400 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Segmentation within 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 00:47:14 -0000 For starters i would look at the UDP NAT tunneling mechinism to provide it. On 03/25/2016 09:16 PM, Tom Henderson wrote: > > On 03/25/2016 03:49 PM, Derek Fawcus wrote: >> Recently I've been working on middlebox s/w: Firewalls and NAT. >> >> One thing this has brought home to me is just how unreliable >> fragmentation is on the current Internet. NAT will often >> simply break it (such that they can not be reassembled) or >> just discard them, and firewalls are often set up to block them. >> >> As such, almost every protocol now would seem to need protocol >> level segmentation/fragmentation, rather than depend up IP >> level fragmentation. >> >> It struck me that it should be quite simple to extend HIP to >> support such. >> >> 1) Add a Controls bit which advertises that the sender supports >> segmentation. >> 2) Define a new parameter, numbered 1 such that it is first in >> the parameters, and is critical. >> Within the parameter have a seqno/identifier, offset and >> more segments / final segment bit, possibly also a total >> size field. Define some simple reassembly rules, similar >> to those for IP fragments, such that one could reassemble >> a HIP packet larger than 2008 bytes if desired (how big?). >> 3) Possibly also define a none critical parameter within the >> non signed, non MACed range which advertises the max size >> packet the sender is willing to reassemble. In fact I guess >> this might remove the need to use a Controls bit, since it >> would imply the sender can reassemble. >> >> Then have a rule that once one party has seen the other party >> advertise the segmentation capability within the current BEX >> session, it is free to make use of segmentation towards that peer. >> >> Thoughts? >> >> DF > Hi Derek, I don't remember the details, but in the early days of HIP, it was decided to avoid the burden of supporting fragmentation. I guess I'd prefer to see some evidence that HIP messages are being fragmented in the wild before starting a work effort to add support. > > - Tom > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Mon Mar 28 23:52:39 2016 Return-Path: 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 29EC712D164 for ; Mon, 28 Mar 2016 23:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-hipsec@employees.org header.d=employees.org 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 RPw9-8yI10N2 for ; Mon, 28 Mar 2016 23:52:37 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4238C12D0A0 for ; Mon, 28 Mar 2016 23:52:37 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id CE63ED788D for ; Mon, 28 Mar 2016 23:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= resent-from:resent-date:resent-message-id:resent-to:date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=ssjuXo4XpDjBYwg6BYiiBsPYn98=; b=PL d7x66jJHHQiFwPHc1/IeaQ4hFWdkMQM6NyH+1JiEGP7ujTu/C7w5R2OM9pFUu7o0 t+hOdfd6SKMADHd3ja/BHw0oL9FPSGvKpiFrAMvujt1Aud2tIX081ODeoV8fcugl Ss1ntZig9BHQSgXCweQZUw6kN8eP0lhgctlnvsdtM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=resent-from :resent-date:resent-message-id:resent-to:date:from:to:cc:subject :message-id:references:mime-version:content-type:in-reply-to; q= dns; s=selector1; b=aXBYiRmvkYzcwrZNgd1v5UB5TcHZEGiYWNJl7VunqNoW 5DTB5bUYqy/Po5M/VGXDPDr/PK1pqDo6/Oi0jVn46Bn6KihI88iqEd2ysXf0YcXR SSk3BDKJGlimiYqXMrLceE7DTJNbPP36FUAtLIAC5RRhtvLViEzmLxDSyUMhkxk= Received: by cowbell.employees.org (Postfix, from userid 1736) id BF42BD7884; Mon, 28 Mar 2016 23:52:36 -0700 (PDT) Resent-From: Derek Fawcus Resent-Date: Tue, 29 Mar 2016 07:52:36 +0100 Resent-Message-ID: <20160329065236.GC12048@cowbell.employees.org> Resent-To: hipsec@ietf.org Date: Tue, 29 Mar 2016 07:50:28 +0100 From: Derek Fawcus To: Robert Moskowitz Message-ID: <20160329065028.GB12048@cowbell.employees.org> Mail-Followup-To: Robert Moskowitz , Tom Henderson , dfawcus+lists-hipsec@employees.org, hipsec@ietf.org References: <56F9D086.1000105@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F9D086.1000105@htt-consult.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Segmentation within 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 06:52:38 -0000 On Mon, Mar 28, 2016 at 08:47:02PM -0400, Robert Moskowitz wrote: > For starters i would look at the UDP NAT tunneling mechinism to provide it. Well, UDP doesn't have any native segmentation / reassembly either; so while it would help in getting across a NAT, it'd not do anything for fragments. I could see someone digging out the scheme which was proposed a while ago for UDP segmentation, and casting it to fit within draft-touch-tsvwg-udp-options-02.txt. DF From nobody Tue Mar 29 00:50:18 2016 Return-Path: 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 2C2E512D56E for ; Tue, 29 Mar 2016 00:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Pn4Aq-wepWXd for ; Tue, 29 Mar 2016 00:50:13 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E6712D0B6 for ; Tue, 29 Mar 2016 00:50:12 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-1d-56fa33b20c51 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 92.C4.22880.2B33AF65; Tue, 29 Mar 2016 09:50:10 +0200 (CEST) Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Tue, 29 Mar 2016 09:50:07 +0200 To: Varjonen Samu References: From: Miika Komu Organization: Ericsson AB Message-ID: <56FA33AF.3030507@ericsson.com> Date: Tue, 29 Mar 2016 10:50:07 +0300 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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050409050201040300020804" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdRnez8a8wg1yLqYsmM1vc+DmD3YHJ o3/lfnaPJUt+MgUwRXHZpKTmZJalFunbJXBlPH24ma1gv33Fs+kP2RsYL1t1MXJySAiYSMy5 vJIZwhaTuHBvPRuILSRwhFFiQZ9ZFyMXkL2aUaLx1UMWkISwgK7E7QlTwWwRILv9YhMLRIOH xNzLf5m6GDk4mAVEJbbPqgIJswloSay6cx1sPr+ApMSGht1gNq+AtsT5B3MYQWwWAVWJzpkn wcaICkRIPJl7khGiRlDi5MwnYHFOAU+J/ftWM4LcwyzQzSix/M0rFpBdQgIqEhePBU9gFJyF pGUWsjKQBLOArcSdubuZIWxtiWULX0PZ1hIzfh1kg7AVJaZ0P2SHsE0lXh/9yAhhG0ssW/eX bQEjxypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwBg5uOW37g7G1a8dDzEKcDAq8fAmrPwZ JsSaWFZcmXuIUQVozqMNqy8wSrHk5eelKonwVon/ChPiTUmsrEotyo8vKs1JLT7EKM3BoiTO y/bpcpiQQHpiSWp2ampBahFMlomDU6qB0UdMSk1mEfPrJVFK85pXbNIvK1Nnt63d//GNb/yN 9cu8tl0ou5zPbfQxk1Fz1YEPi1XCgpP7lh374Pp5h+DUzJ/STncOXrCQE0n7ytniGbNFKKjm 8YZHG16edH6j2mCQUHt173J/gZumxjX63GEKZof91D+IWzguba3eoP9/588+A3tbtpYsJZbi jERDLeai4kQA8YOGG5kCAAA= Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Segmentation within 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 07:50:15 -0000 --------------ms050409050201040300020804 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Samu, On 03/26/2016 03:16 AM, Tom Henderson wrote: > > > On 03/25/2016 03:49 PM, Derek Fawcus wrote: >> Recently I've been working on middlebox s/w: Firewalls and NAT. >> >> One thing this has brought home to me is just how unreliable >> fragmentation is on the current Internet. NAT will often simply >> break it (such that they can not be reassembled) or just discard >> them, and firewalls are often set up to block them. >> >> As such, almost every protocol now would seem to need protocol >> level segmentation/fragmentation, rather than depend up IP level >> fragmentation. >> >> It struck me that it should be quite simple to extend HIP to >> support such. >> >> 1) Add a Controls bit which advertises that the sender supports >> segmentation. 2) Define a new parameter, numbered 1 such that it >> is first in the parameters, and is critical. Within the parameter >> have a seqno/identifier, offset and more segments / final segment >> bit, possibly also a total size field. Define some simple >> reassembly rules, similar to those for IP fragments, such that one >> could reassemble a HIP packet larger than 2008 bytes if desired >> (how big?). 3) Possibly also define a none critical parameter >> within the non signed, non MACed range which advertises the max >> size packet the sender is willing to reassemble. In fact I guess >> this might remove the need to use a Controls bit, since it would >> imply the sender can reassemble. >> >> Then have a rule that once one party has seen the other party >> advertise the segmentation capability within the current BEX >> session, it is free to make use of segmentation towards that peer. >> >> Thoughts? >> >> DF > > Hi Derek, I don't remember the details, but in the early days of HIP, > it was decided to avoid the burden of supporting fragmentation. I > guess I'd prefer to see some evidence that HIP messages are being > fragmented in the wild before starting a work effort to add support. do you recall how long a typical X.509 certificate can get? --------------ms050409050201040300020804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzI5MDc1MDA3 WjAvBgkqhkiG9w0BCQQxIgQg6dYjEux/Lq21T61qxPKIiEj3X9nu0VnWCnq2mK7JRyYwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCj31WRp3e7 EEnEfUkJ8lMxf1VRzIpXbPP0Guw5YXleu2TJ/5j4llvI89NOphGX9XzCPfwE5ypFuR9HmAoo DhVDMqZ7TYGG8WEE7X1ACbGLq7o4BfEiT8c7Dp+IB1C2FIT/HM5hRTwNs8eBbcYcI2WhShFC V4Ada3i1EN1pREawj8q2zbb7ycnPJTFjWnIqitbnLNPhDrE2AiK+Qp3NJR3lOt8wc5EDvlM3 eMGIIKIAXuuonWs5C8gklWR/aAj6SQdPOboR77FwJBdm8BNc8bCAjYn0x/5u64x/qdlaMWWm +KzbGaV9nOdMfRwGHZWO0Z6bmKzFLI3kwyctFm1Tpa6bAAAAAAAA --------------ms050409050201040300020804-- From nobody Tue Mar 29 07:14:38 2016 Return-Path: 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 4830112D84E for ; Tue, 29 Mar 2016 07:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AZyRLEb_7gV2 for ; Tue, 29 Mar 2016 07:14:35 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6528A12D857 for ; Tue, 29 Mar 2016 07:14:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5E0796226B; Tue, 29 Mar 2016 10:14:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id njFuD8KnsRCX; Tue, 29 Mar 2016 10:14:26 -0400 (EDT) Received: from lx120e.htt-consult.com (181.sub-70-208-79.myvzw.com [70.208.79.181]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 69D696225D; Tue, 29 Mar 2016 10:14:21 -0400 (EDT) To: Tom Henderson , dfawcus+lists-hipsec@employees.org, hipsec@ietf.org References: <56F9D086.1000105@htt-consult.com> <20160329065028.GB12048@cowbell.employees.org> From: Robert Moskowitz Message-ID: <56FA8DBA.5030205@htt-consult.com> Date: Tue, 29 Mar 2016 10:14:18 -0400 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: <20160329065028.GB12048@cowbell.employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Hipsec] Segmentation within 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 14:14:37 -0000 That is why I recommended you look at what Sue and I are developing for a session layer service on top of any transport that would provide this. And of course it is always worthwhile to look at anything Joe Touch worked on.... On 03/29/2016 02:50 AM, Derek Fawcus wrote: > On Mon, Mar 28, 2016 at 08:47:02PM -0400, Robert Moskowitz wrote: >> For starters i would look at the UDP NAT tunneling mechinism to provide it. > Well, UDP doesn't have any native segmentation / reassembly either; > so while it would help in getting across a NAT, it'd not do anything > for fragments. > > I could see someone digging out the scheme which was proposed a while > ago for UDP segmentation, and casting it to fit within > draft-touch-tsvwg-udp-options-02.txt. > > DF > From nobody Tue Mar 29 07:29:03 2016 Return-Path: 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 43F2C12D885 for ; Tue, 29 Mar 2016 07:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Ld9oFAFwfgVF for ; Tue, 29 Mar 2016 07:29:00 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52C812D878 for ; Tue, 29 Mar 2016 07:28:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4A53562269; Tue, 29 Mar 2016 10:28:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cTE7wgM75mlF; Tue, 29 Mar 2016 10:28:13 -0400 (EDT) Received: from lx120e.htt-consult.com (181.sub-70-208-79.myvzw.com [70.208.79.181]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 7715D62265; Tue, 29 Mar 2016 10:28:12 -0400 (EDT) To: Miika Komu , Varjonen Samu References: <56FA33AF.3030507@ericsson.com> From: Robert Moskowitz Message-ID: <56FA90F9.9090807@htt-consult.com> Date: Tue, 29 Mar 2016 10:28:09 -0400 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: <56FA33AF.3030507@ericsson.com> Content-Type: multipart/alternative; boundary="------------000403060606030801090906" Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Segmentation within 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 14:29:02 -0000 This is a multi-part message in MIME format. --------------000403060606030801090906 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit While working on 802.15.9, Tero and I discussed this. IKEv1 allowed for REALLY BIG cert chains and had lots or problems even without NATs. IKEv2 is more restrictive such that we designed 15.9 worst case frag/reassem to be 24KB (more than enough per Tero): "4.7 KMP Payload Size As the MP Data layer allows a KMP payload to be fragmented up to 256 fragments, this means that even if the PHY is using 127 octet PSDUs (96 octets effective fragment size), this recommended practice can use KMP payloads up to 24 576 octets." If you design a UDP service that supports 32 fragments (5 bit counter), you can support payloads of ~15KB. On 03/29/2016 03:50 AM, Miika Komu wrote: > Hi Samu, > > On 03/26/2016 03:16 AM, Tom Henderson wrote: >> >> >> On 03/25/2016 03:49 PM, Derek Fawcus wrote: >>> Recently I've been working on middlebox s/w: Firewalls and NAT. >>> >>> One thing this has brought home to me is just how unreliable >>> fragmentation is on the current Internet. NAT will often simply >>> break it (such that they can not be reassembled) or just discard >>> them, and firewalls are often set up to block them. >>> >>> As such, almost every protocol now would seem to need protocol >>> level segmentation/fragmentation, rather than depend up IP level >>> fragmentation. >>> >>> It struck me that it should be quite simple to extend HIP to >>> support such. >>> >>> 1) Add a Controls bit which advertises that the sender supports >>> segmentation. 2) Define a new parameter, numbered 1 such that it >>> is first in the parameters, and is critical. Within the parameter >>> have a seqno/identifier, offset and more segments / final segment >>> bit, possibly also a total size field. Define some simple >>> reassembly rules, similar to those for IP fragments, such that one >>> could reassemble a HIP packet larger than 2008 bytes if desired >>> (how big?). 3) Possibly also define a none critical parameter >>> within the non signed, non MACed range which advertises the max >>> size packet the sender is willing to reassemble. In fact I guess >>> this might remove the need to use a Controls bit, since it would >>> imply the sender can reassemble. >>> >>> Then have a rule that once one party has seen the other party >>> advertise the segmentation capability within the current BEX >>> session, it is free to make use of segmentation towards that peer. >>> >>> Thoughts? >>> >>> DF >> >> Hi Derek, I don't remember the details, but in the early days of HIP, >> it was decided to avoid the burden of supporting fragmentation. I >> guess I'd prefer to see some evidence that HIP messages are being >> fragmented in the wild before starting a work effort to add support. > > do you recall how long a typical X.509 certificate can get? > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --------------000403060606030801090906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit While working on 802.15.9, Tero and I discussed this.  IKEv1 allowed for REALLY BIG cert chains and had lots or problems even without NATs.  IKEv2 is more restrictive such that we designed 15.9 worst case frag/reassem to be 24KB (more than enough per Tero):

"4.7 KMP Payload Size

As the MP Data layer allows a KMP payload to be fragmented up to 256 fragments, this means that even if
the PHY is using 127 octet PSDUs (96 octets effective fragment size), this recommended practice can use
KMP payloads up to 24 576 octets."

If you design a UDP service that supports 32 fragments (5 bit counter), you can support payloads of ~15KB.


On 03/29/2016 03:50 AM, Miika Komu wrote:
Hi Samu,

On 03/26/2016 03:16 AM, Tom Henderson wrote:


On 03/25/2016 03:49 PM, Derek Fawcus wrote:
Recently I've been working on middlebox s/w:  Firewalls and NAT.

One thing this has brought home to me is just how unreliable
fragmentation is on the current Internet.  NAT will often simply
break it (such that they can not be reassembled) or just discard
them,  and firewalls are often set up to block them.

As such,  almost every protocol now would seem to need protocol
level segmentation/fragmentation,  rather than depend up IP level
fragmentation.

It struck me that it should be quite simple to extend HIP to
support such.

1) Add a Controls bit which advertises that the sender supports
segmentation. 2) Define a new parameter,  numbered 1 such that it
is first in the parameters,  and is critical. Within the parameter
have a seqno/identifier, offset and more segments / final segment
bit, possibly also a total size field.  Define some simple
reassembly rules,  similar to those for IP fragments, such that one
could reassemble a HIP packet larger than 2008 bytes if desired
(how big?). 3) Possibly also define a none critical parameter
within the non signed,  non MACed range which advertises the max
size packet the sender is willing to reassemble.  In fact I guess
this might remove the need to use a Controls bit,  since it would
imply the sender can reassemble.

Then have a rule that once one party has seen the other party
advertise the segmentation capability within the current BEX
session, it is free to make use of segmentation towards that peer.

Thoughts?

DF

Hi Derek, I don't remember the details, but in the early days of HIP,
it was decided to avoid the burden of supporting fragmentation.  I
guess I'd prefer to see some evidence that HIP messages are being
fragmented in the wild before starting a work effort to add support.

do you recall how long a typical X.509 certificate can get? 



_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

--------------000403060606030801090906-- From nobody Thu Mar 31 07:35:48 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA84512D1A3 for ; Thu, 31 Mar 2016 07:31:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160331143128.28679.59638.idtracker@ietfa.amsl.com> Date: Thu, 31 Mar 2016 07:31:28 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Thu, 31 Mar 2016 07:35:47 -0700 Subject: [Hipsec] Milestones changed for hip WG X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 14:31:29 -0000 Changed milestone "WGLC the specification on how to build HIP-based overlays using RELOAD", resolved as "Done". Changed milestone "Submit the specification on how to build HIP-based overlays using RELOAD to the IESG", resolved as "Done". Changed milestone "WGLC RFC4843bis", resolved as "Done". Changed milestone "WGLC RFC5201bis", resolved as "Done". Changed milestone "WGLC RFC5202bis", resolved as "Done". Changed milestone "Submit RFC5201bis to the IESG", resolved as "Done". Changed milestone "Submit RFC4843bis to the IESG", resolved as "Done". Changed milestone "Submit RFC5202bis to the IESG", resolved as "Done". Changed milestone "WGLC RFC5203bis", resolved as "Done". Changed milestone "WGLC RFC5204bis", resolved as "Done". Changed milestone "WGLC RFC5205bis", resolved as "Done". Changed milestone "Submit RFC5203bis to the IESG", resolved as "Done". Changed milestone "Submit RFC5204bis to the IESG", resolved as "Done". Changed milestone "Submit RFC5205bis to the IESG", resolved as "Done". Changed milestone "WGLC RFC5770bis", resolved as "Done". Changed milestone "WGLC Certs in HIP base exchange specification (referencing RFC5201bis)", resolved as "Done". Changed milestone "Submit Certs in HIP base exchange (referencing RFC5201bis) to the IESG as PS", resolved as "Done". Changed milestone "Submit RFC5770bis to the IESG", set due date to April 2016 from October 2011. Changed milestone "WGLC the multihoming portion of RFC5206bis", set due date to April 2016 from September 2011. Changed milestone "WGLC the mobility portion of RFC5206bis", set due date to April 2016 from July 2011. Changed milestone "Submit the multihoming portion of RFC5206bis to the IESG", set due date to June 2016 from October 2011. Changed milestone "Submit the mobility portion of RFC5206bis to the IESG", set due date to June 2016 from August 2011. Changed milestone "WGLC RFC4423bis", set due date to October 2016 from May 2011. Changed milestone "Submit RFC4423bis to the IESG", set due date to December 2016 from June 2011. Changed milestone "Recharter or close the WG", set due date to January 2017 from January 2012. URL: https://datatracker.ietf.org/wg/hip/charter/ From nobody Thu Mar 31 07:38:26 2016 Return-Path: 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 9226F12D156 for ; Thu, 31 Mar 2016 07:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 O6MFkQ8N_CoZ for ; Thu, 31 Mar 2016 07:38:18 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546B812D153 for ; Thu, 31 Mar 2016 07:38:17 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-86-56fd36576138 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.D4.16394.7563DF65; Thu, 31 Mar 2016 16:38:15 +0200 (CEST) Received: from [148.135.149.145] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Thu, 31 Mar 2016 16:37:41 +0200 To: References: <20160331143128.28679.59638.idtracker@ietfa.amsl.com> From: Gonzalo Camarillo Message-ID: <56FD3635.7010302@ericsson.com> Date: Thu, 31 Mar 2016 17:37:41 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160331143128.28679.59638.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM2K7hG642d8wg85VuhZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrVTP9gK5opVvGlQbmD8KNjFyMkhIWAicXPBCUYIW0ziwr31 bF2MXBxCAkcYJbpO/GIDSQgJrGWUmPxZEcQWFjCW2PjmLguILSIgKjHlw2lmiBpHiR8rWsFs NgELiS237oPV8ApoSzzt+8wKYrMIqEpM2b6GCcQWFYiROP7uHCNEjaDEyZlPwOo5BZwk+p72 gtUwCxhIHFk0hxXClpfY/nYO1C5tieXPWlgmMArMQtI+C0nLLCQtCxiZVzGKFqcWJ+WmGxnr pRZlJhcX5+fp5aWWbGIEBuDBLb9VdzBefuN4iFGAg1GJh3dBy58wIdbEsuLK3EOMEhzMSiK8 fqZ/w4R4UxIrq1KL8uOLSnNSiw8xSnOwKInzsn66HCYkkJ5YkpqdmlqQWgSTZeLglGpgNGib fe9v5eXVWSkWFrvEFfdPml39OWyRgFWH3FWx8P9Rbfxu37e7f5zy2bpm1pfgr7ZlmUqNm3/q 3N1/dvIWZ9E5u00XxU58+W8xr/v9CSVLGq9+c+JIXK3MNPX9T+bERewcu43umvK81tt7QTB6 8xbhuk6e1tL1P5tmZ00U28PxWcr54RyZHCWW4oxEQy3mouJEAPvrKfs8AgAA Archived-At: Subject: Re: [Hipsec] Milestones changed for hip WG 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 14:38:24 -0000 Folks, I have updated our milestones per our discussion. I have talked with our responsible AD and he told me that we do not need to update the charter text in order to add the HIP DEX milestone. So, I have left the text as it was. Cheers, Gonzalo On 31/03/2016 5:31 PM, IETF Secretariat wrote: > Changed milestone "WGLC the specification on how to build HIP-based > overlays using RELOAD", resolved as "Done". > > Changed milestone "Submit the specification on how to build HIP-based > overlays using RELOAD to the IESG", resolved as "Done". > > Changed milestone "WGLC RFC4843bis", resolved as "Done". > > Changed milestone "WGLC RFC5201bis", resolved as "Done". > > Changed milestone "WGLC RFC5202bis", resolved as "Done". > > Changed milestone "Submit RFC5201bis to the IESG", resolved as "Done". > > Changed milestone "Submit RFC4843bis to the IESG", resolved as "Done". > > Changed milestone "Submit RFC5202bis to the IESG", resolved as "Done". > > Changed milestone "WGLC RFC5203bis", resolved as "Done". > > Changed milestone "WGLC RFC5204bis", resolved as "Done". > > Changed milestone "WGLC RFC5205bis", resolved as "Done". > > Changed milestone "Submit RFC5203bis to the IESG", resolved as "Done". > > Changed milestone "Submit RFC5204bis to the IESG", resolved as "Done". > > Changed milestone "Submit RFC5205bis to the IESG", resolved as "Done". > > Changed milestone "WGLC RFC5770bis", resolved as "Done". > > Changed milestone "WGLC Certs in HIP base exchange specification > (referencing RFC5201bis)", resolved as "Done". > > Changed milestone "Submit Certs in HIP base exchange (referencing > RFC5201bis) to the IESG as PS", resolved as "Done". > > Changed milestone "Submit RFC5770bis to the IESG", set due date to > April 2016 from October 2011. > > Changed milestone "WGLC the multihoming portion of RFC5206bis", set > due date to April 2016 from September 2011. > > Changed milestone "WGLC the mobility portion of RFC5206bis", set due > date to April 2016 from July 2011. > > Changed milestone "Submit the multihoming portion of RFC5206bis to the > IESG", set due date to June 2016 from October 2011. > > Changed milestone "Submit the mobility portion of RFC5206bis to the > IESG", set due date to June 2016 from August 2011. > > Changed milestone "WGLC RFC4423bis", set due date to October 2016 from > May 2011. > > Changed milestone "Submit RFC4423bis to the IESG", set due date to > December 2016 from June 2011. > > Changed milestone "Recharter or close the WG", set due date to January > 2017 from January 2012. > > URL: https://datatracker.ietf.org/wg/hip/charter/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Thu Mar 31 07:40:02 2016 Return-Path: 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 698D912D199 for ; Thu, 31 Mar 2016 07:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 UcvouJO_cdmx for ; Thu, 31 Mar 2016 07:39:59 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8422112D189 for ; Thu, 31 Mar 2016 07:39:57 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-27-56fd36bb8f88 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.C7.22880.BB63DF65; Thu, 31 Mar 2016 16:39:55 +0200 (CEST) Received: from [148.135.149.145] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.248.2; Thu, 31 Mar 2016 16:39:54 +0200 To: Varjonen Samu , References: <20160226092518.23119.26137.idtracker@ietfa.amsl.com> <56D01ACE.50907@cs.helsinki.fi> From: Gonzalo Camarillo Message-ID: <56FD36BA.9020002@ericsson.com> Date: Thu, 31 Mar 2016 17:39:54 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D01ACE.50907@cs.helsinki.fi> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7qO5us79hBm8mKFtMXTSZ2eLb8yWM Dkwea69ZeCxZ8pMpgCmKyyYlNSezLLVI3y6BK+PzkxVsBVNEKr7P/8nYwPicv4uRk0NCwESi 69N1dghbTOLCvfVsXYxcHEICRxgl9q/5zQLhrGWU+LN6BjNIlbCAs0TX+musXYwcHCJA9vcZ YIOEBJIljh+aywJiswlYSGy5dR/M5hXQlvjxuRlsAYuAqsT0Td+YQGxRgRiJ4+/OMULUCEqc nPkErJ5TQEfiQPt0sDizgIHEkUVzWCFseYntb+cwQ+zSllj+rIVlAqPALCTts5C0zELSsoCR eRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYFAe3PJbdwfj6teOhxgFOBiVeHgXtPwJE2JN LCuuzD3EKMHBrCTC22n6N0yINyWxsiq1KD++qDQntfgQozQHi5I4L9uny2FCAumJJanZqakF qUUwWSYOTqkGxqYZmlOD+jatMlIVnvw011Tf54Kc3Wonht6DR6Z6BsiK+LXeeqwpu+LKMcYl 8wXuSAfsKZ6UnL/9+ZVKbWV5ZnO9mXON/efNONFUcKJd2Ddm8+z1adOcboS3vZK4nzbPn//u 6h3Z6tKNlzz95i/iFmMSe541kc32vbJqB5uYNucT74BDvllBSizFGYmGWsxFxYkAOKyYz0YC AAA= Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 14:40:01 -0000 Hi Samu, what is the status of this? Thanks, Gonzalo On 26/02/2016 11:28 AM, Varjonen Samu wrote: > Hi all, > > addressed the GenArt, OPSdir, SecDir, and IANA comments. Still waiting > for one clarification to one last comment. > > -Samu > > On 26/02/16 11:25, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Host Identity Protocol of the IETF. >> >> Title : Host Identity Protocol Certificates >> Authors : Tobias Heer >> Samu Varjonen >> Filename : draft-ietf-hip-rfc6253-bis-07.txt >> Pages : 11 >> Date : 2016-02-26 >> >> Abstract: >> The Certificate (CERT) parameter is a container for digital >> certificates. It is used for carrying these certificates in Host >> Identity Protocol (HIP) control packets. This document specifies the >> certificate parameter and the error signaling in case of a failed >> verification. Additionally, this document specifies the >> representations of Host Identity Tags in X.509 version 3 (v3). >> >> The concrete use cases of certificates, including how certificates >> are obtained, requested, and which actions are taken upon successful >> or failed verification, are specific to the scenario in which the >> certificates are used. Hence, the definition of these scenario- >> specific aspects is left to the documents that use the CERT >> parameter. >> >> This document updates RFC7401 and obsoletes RFC6253. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-07 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 > From nobody Thu Mar 31 07:44:45 2016 Return-Path: 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 F179112D1CF for ; Thu, 31 Mar 2016 07:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.202 X-Spam-Level: X-Spam-Status: No, score=-104.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, USER_IN_WHITELIST=-100] 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 qNR3VxmLOSAQ for ; Thu, 31 Mar 2016 07:44:42 -0700 (PDT) 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 5DDAC12D18D for ; Thu, 31 Mar 2016 07:44:42 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-1f-56fd37d84ffc Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E7.60.23401.8D73DF65; Thu, 31 Mar 2016 16:44:40 +0200 (CEST) Received: from [148.135.149.145] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.248.2; Thu, 31 Mar 2016 16:44:11 +0200 To: Tom Henderson References: <56B36901.1030407@ericsson.com> From: Gonzalo Camarillo Message-ID: <56FD37BB.1090907@ericsson.com> Date: Thu, 31 Mar 2016 17:44:11 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56B36901.1030407@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2K7se4N879hBov7tC2mLprMbDHz/EE2 ByaPJUt+Mnm0XI8JYIrisklJzcksSy3St0vgymh6YlPwTKhiwu7zLA2MG/m7GDk5JARMJL78 +MUGYYtJXLi3Hsjm4hASOMIosfrNfShnLaPE1QdTWECqhAX0JLZdn8QOYosI6EhcerGFFcQW EsiWuHD3JVgNs4CkxPJNEFPZBCwktty6DxbnFdCW+LJyI1icRUBV4tmM32C9ogIxEsffnWOE qBGUODnzCVA9Bwcn0Pze5XIQIw0kjiyawwphy0s0b53NDLFWW2L5sxaWCYyCs5B0z0LSMgtJ ywJG5lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgaF6cMtvqx2MB587HmIU4GBU4uFd0PIn TIg1say4MvcQowQHs5II7ymzv2FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEedk+XQ4TEkhPLEnN Tk0tSC2CyTJxcEo1MJpMXSNW3Del5WmgaoKFS9953Y+zrryU6VvNzbxSdM3bE00tt7bVH+Fc HFy6MUOO1TS2Qeq7ZkLyo9uzGn631N206Wa4JPDSaPqV+Z6bt9ywW6Af/0zf3NNa9+Cj+OX6 p+Q++BzU8ph0+lbL9EWrmG8W11pnnHjVmflQQW/VjQ0GgVXTFrROzVBiKc5INNRiLipOBAB6 RIFqUQIAAA== Archived-At: Cc: HIP Subject: Re: [Hipsec] Status of our next batch 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 14:44:45 -0000 Hi Tom, what is the status of the multihoming draft? When do you think you will get around to submitting a version that is ready for WGLC? Thanks, Gonzalo On 04/02/2016 5:06 PM, Gonzalo Camarillo wrote: > Hi Tom, > > thanks for the update. We will wait until you get around to revising the > multihoming draft as well and then we will WGLC them together. > > Cheers, > > Gonzalo > > On 01/02/2016 7:59 AM, Tom Henderson wrote: >> >> >> On 11/17/2015 11:52 PM, Gonzalo Camarillo wrote: >>> Authors of the following drafts, >>> >>> could you please let the WG know their status and what needs to happen >>> next for each of them in order to be able to WGLC them at some point in >>> the future? >>> >>> https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ >>> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ >>> http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ >>> >>> Thanks, >>> >>> Gonzalo >> >> Gonzalo and all, >> >> Here is a brief update on the mobility and multihoming drafts. I posted a revision 10 of RFC5206-bis last week: >> https://www.ietf.org/id/draft-ietf-hip-rfc5206-bis-10.txt >> >> I believe that we could close all the remaining open issues as either resolved or wontfix (editorial); the changes that appear in draft-10 are as follows: >> - issue 21: clarified that HI MAY be included in UPDATE >> for benefit of middleboxes >> - changed one informative reference from RFC 4423-bis to RFC 7401 >> - removed discussion about possible multiple LOCATOR_SET >> and ESP_INFO parameters in an UPDATE (per previous >> mailing list discussion) >> - removed discussion about handling LOCATOR_SET parameters in packets >> other than UPDATE (per previous mailing list discussion) >> >> I had hoped to post a revision of the multihoming draft with all of the open issues resolved by now, but there is still some work for me to do, so I just refreshed the previous version for the time being: >> https://www.ietf.org/id/draft-ietf-hip-multihoming-07.txt >> >> I will work on publishing -08 shortly and then I think we could consider a WGLC on the pair of drafts. >> >> - Tom >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Thu Mar 31 07:47:18 2016 Return-Path: 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 3DED212D186 for ; Thu, 31 Mar 2016 07:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 u6j-zaQgodeh for ; Thu, 31 Mar 2016 07:47:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3EBE12D1CF for ; Thu, 31 Mar 2016 07:47:04 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-82-56fd3867ca1b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F0.86.16394.7683DF65; Thu, 31 Mar 2016 16:47:03 +0200 (CEST) Received: from [148.135.149.145] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Thu, 31 Mar 2016 16:46:22 +0200 To: Miika Komu , References: <56CDBDA1.7050207@ericsson.com> <3CEE85EA-C996-4B28-B0A3-DA8B158BD159@temperednetworks.com> <56D1630A.7000209@ericsson.com> <56D45895.2060503@ericsson.com> <56DD757B.8050002@ericsson.com> From: Gonzalo Camarillo Message-ID: <56FD383D.8050200@ericsson.com> Date: Thu, 31 Mar 2016 17:46:21 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56DD757B.8050002@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM2K7rm66xd8wg3+NQhZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq9pP1gKrolWrHt+mbGBcYVgFyMnh4SAicTaS7dYIGwxiQv3 1rN1MXJxCAkcYZS483kjI4SzllHi4ffVYFXCAvYSJ/fdYgexRQSsJT5cXs4EUdTLJPF61iY2 kASbgIXEllv3wRp4BbQlNt2YC9bAIqAqMXH9N7C4qECMxPF35xghagQlTs58AhbnFNCRWLSk jwnEZhYwkDiyaA4rhC0vsf3tHGYQWwho5vJnLSwTGAVmIWmfhaRlFpKWBYzMqxhFi1OLk3LT jYz1Uosyk4uL8/P08lJLNjECw/Dglt+qOxgvv3E8xCjAwajEw7ug5U+YEGtiWXFl7iFGCQ5m JRFePfO/YUK8KYmVValF+fFFpTmpxYcYpTlYlMR5WT9dDhMSSE8sSc1OTS1ILYLJMnFwSjUw tn1mWn8+KDjSw/h5jFdCyTVn1i/BPqmdkzks9pdF75wTOfnvRKGpy5aIH/p21CalW+jJgbqv K1dMdF7Yxe5v88z/ZsefX0wyi3bfd3m0SPFpyztHNs+fi7co3s3bIzC3ROJid3nXAYPt9Sdv ds2R0XycfjGl/mnkcpntamI7jQOU80sCJx8PVWIpzkg01GIuKk4EACSSxYo/AgAA Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 14:47:17 -0000 Hi Miika, what is the status of this? Thanks, Gonzalo On 07/03/2016 2:35 PM, Gonzalo Camarillo wrote: > Hi, > > I have just talked with Miika and he has volunteered to take the pen and > add the necessary clarifications to the draft so that it is more > readable. Thanks, Miika! > > First he will look into adding clarifications to the existing draft > while still referencing the old RFC. If the group is not happy with the > readability after the editorial pass (or our AD does not finally let us > downref the old RFC), we can consider bringing material from the old RFC > directly into the new one. > > I would also like the group to comment on the following two proposals: > > 1) the draft will allow implementers to use HIP native relays only. In > addition, the use of STUN and TURN relays will be optional. > > 2) in addition to covering the base exchange, the draft will also cover > the mobility readdressing exchange. > > Thanks, > > Gonzalo > > On 29/02/2016 4:41 PM, Miika Komu wrote: >> Hi, >> >> On 02/27/2016 10:49 AM, Gonzalo Camarillo wrote: >>> Hi Jeff, >>> >>> thanks for your feedback. >>> >>>> Regarding pros/cons: >>>> How widely-deployed is STUN/TURN? Are public servers widespread? >>> >>> there are several of them. They are mostly used for VoIP. You can google >>> for "public stun turn servers" or something similar. There are a few >>> lists out there. >> >> I guess the situation is like this: >> >> HIP control plane relay: >> * new critical infrastructure that needs to be deployed anyway (TURN >> server cannot be used for this) >> >> Gathering of address candidates: >> * from a STUN server (many available) >> * ...or from control plane relay registration (which is mandatory anyway) >> >> Data plane relay: >> * using TURN server (it seems some are available) >> * ...or using the ESP relay as specified in native NAT spec (none >> deployed, but I guess could co-locate with the HIP control plane relay) >> >> So, the critical part are the HIP control plane relays which provide >> also similar functionality as STUN servers (i.e. provide server >> reflexive candidates). So I guess the question boils down to the >> availability of TURN servers. >> >> P.S. Nothing really prevents to use STUN servers to discover address >> candidates in the native NAT traversal version. The discovery process is >> independent of the NAT penetration process. >> >> >> >> _______________________________________________ >> 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 > From nobody Thu Mar 31 08:14:01 2016 Return-Path: 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 D62F912D0D8 for ; Thu, 31 Mar 2016 08:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 7ZuFfKWfj8Df for ; Thu, 31 Mar 2016 08:13:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FDA12D199 for ; Thu, 31 Mar 2016 08:13:57 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-84-56fd3eb3271c Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.D8.30858.3BE3DF65; Thu, 31 Mar 2016 17:13:56 +0200 (CEST) Received: from [148.135.149.145] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.248.2; Thu, 31 Mar 2016 17:12:01 +0200 To: References: <20160325224921.GA75376@cowbell.employees.org> From: Gonzalo Camarillo Message-ID: <56FD3E40.9080200@ericsson.com> Date: Thu, 31 Mar 2016 18:12:00 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160325224921.GA75376@cowbell.employees.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2J7iO4Wu79hBhsWcFlMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGd/7Z7MU9AtUHJy8kbGB8TxPFyMnh4SAicSEU3cZIWwxiQv3 1rN1MXJxCAkcYZQ4MeksK0hCSGAto8SuPiEQW1hAV+L2hKksILaIgKjElA+nmSFqrCRa/30C G8QmYCGx5dZ9sBpeAW2J7svH2EBsFgFViQWvOthBbFGBGInj784xQtQISpyc+QSsnlPAWuLl spdgNrOAgcSRRXNYIWx5ie1v50Dt0pZY/qyFZQKjwCwk7bOQtMxC0rKAkXkVo2hxanFSbrqR kV5qUWZycXF+nl5easkmRmAIHtzy22AH48vnjocYBTgYlXh4F7T8CRNiTSwrrsw9xCjBwawk wvvY9m+YEG9KYmVValF+fFFpTmrxIUZpDhYlcV7WT5fDhATSE0tSs1NTC1KLYLJMHJxSDYzz b+cr8f98wDzLaJPhusczQ0My+fQeLinxKXlhUvT142H9qxuU1Pd9N/9xVj/79HaFOfetZ/lu Nkz77rdsv8ujzG1+upYvtpesnT2/uOLaikeMGlJ1d/V7Xx+oqUma1pWSFPdJvpvJI7J6HdNE OYUlxi69r60OvnjH0mh3dLn8PUtz2RqZsldKLMUZiYZazEXFiQA+rkThPQIAAA== Archived-At: Subject: Re: [Hipsec] Segmentation within 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 15:14:00 -0000 Hi, when specified the HIP_DATA packets we noted the fragmentation problem but simply advised against sending large packets, which sure is not a great solution ;-) https://tools.ietf.org/html/rfc6078#section-6 Cheers, Gonzalo On 26/03/2016 12:49 AM, Derek Fawcus wrote: > Recently I've been working on middlebox s/w: Firewalls and NAT. > > One thing this has brought home to me is just how unreliable > fragmentation is on the current Internet. NAT will often > simply break it (such that they can not be reassembled) or > just discard them, and firewalls are often set up to block them. > > As such, almost every protocol now would seem to need protocol > level segmentation/fragmentation, rather than depend up IP > level fragmentation. > > It struck me that it should be quite simple to extend HIP to > support such. > > 1) Add a Controls bit which advertises that the sender supports > segmentation. > 2) Define a new parameter, numbered 1 such that it is first in > the parameters, and is critical. > Within the parameter have a seqno/identifier, offset and > more segments / final segment bit, possibly also a total > size field. Define some simple reassembly rules, similar > to those for IP fragments, such that one could reassemble > a HIP packet larger than 2008 bytes if desired (how big?). > 3) Possibly also define a none critical parameter within the > non signed, non MACed range which advertises the max size > packet the sender is willing to reassemble. In fact I guess > this might remove the need to use a Controls bit, since it > would imply the sender can reassemble. > > Then have a rule that once one party has seen the other party > advertise the segmentation capability within the current BEX > session, it is free to make use of segmentation towards that peer. > > Thoughts? > > DF > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Thu Mar 31 14:54:06 2016 Return-Path: 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 8A9AE12D1B0 for ; Thu, 31 Mar 2016 14:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UUTo0X50x2Wb for ; Thu, 31 Mar 2016 14:54:01 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1E912D0B8 for ; Thu, 31 Mar 2016 14:54:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D461C62371; Thu, 31 Mar 2016 17:53:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gRW9FDf4Yk4r; Thu, 31 Mar 2016 17:53:52 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 225E162367; Thu, 31 Mar 2016 17:53:52 -0400 (EDT) To: Gonzalo Camarillo , hipsec@ietf.org References: <20160325224921.GA75376@cowbell.employees.org> <56FD3E40.9080200@ericsson.com> From: Robert Moskowitz Message-ID: <56FD9C6C.9050201@htt-consult.com> Date: Thu, 31 Mar 2016 17:53:48 -0400 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: <56FD3E40.9080200@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Hipsec] Segmentation within 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 21:54:04 -0000 As I said, I am seeing this as part of a larger problem. And am working on some ideas. On 03/31/2016 11:12 AM, Gonzalo Camarillo wrote: > Hi, > > when specified the HIP_DATA packets we noted the fragmentation problem > but simply advised against sending large packets, which sure is not a > great solution ;-) > > https://tools.ietf.org/html/rfc6078#section-6 > > Cheers, > > Gonzalo > > On 26/03/2016 12:49 AM, Derek Fawcus wrote: >> Recently I've been working on middlebox s/w: Firewalls and NAT. >> >> One thing this has brought home to me is just how unreliable >> fragmentation is on the current Internet. NAT will often >> simply break it (such that they can not be reassembled) or >> just discard them, and firewalls are often set up to block them. >> >> As such, almost every protocol now would seem to need protocol >> level segmentation/fragmentation, rather than depend up IP >> level fragmentation. >> >> It struck me that it should be quite simple to extend HIP to >> support such. >> >> 1) Add a Controls bit which advertises that the sender supports >> segmentation. >> 2) Define a new parameter, numbered 1 such that it is first in >> the parameters, and is critical. >> Within the parameter have a seqno/identifier, offset and >> more segments / final segment bit, possibly also a total >> size field. Define some simple reassembly rules, similar >> to those for IP fragments, such that one could reassemble >> a HIP packet larger than 2008 bytes if desired (how big?). >> 3) Possibly also define a none critical parameter within the >> non signed, non MACed range which advertises the max size >> packet the sender is willing to reassemble. In fact I guess >> this might remove the need to use a Controls bit, since it >> would imply the sender can reassemble. >> >> Then have a rule that once one party has seen the other party >> advertise the segmentation capability within the current BEX >> session, it is free to make use of segmentation towards that peer. >> >> Thoughts? >> >> DF >> >> _______________________________________________ >> 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 >