From hipsec-bounces@ietf.org Wed Aug 6 00:24:21 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1B73A691E; Wed, 6 Aug 2008 00:24:21 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24D43A6820 for ; Wed, 6 Aug 2008 00:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.452 X-Spam-Level: ** X-Spam-Status: No, score=2.452 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh5IwjG-+ca1 for ; Wed, 6 Aug 2008 00:19:48 -0700 (PDT) Received: from bay0-omc1-s21.bay0.hotmail.com (bay0-omc1-s21.bay0.hotmail.com [65.54.246.93]) by core3.amsl.com (Postfix) with ESMTP id 155143A6AA5 for ; Wed, 6 Aug 2008 00:19:31 -0700 (PDT) Received: from BAY117-W22 ([207.46.8.57]) by bay0-omc1-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 00:19:30 -0700 Message-ID: X-Originating-IP: [218.2.216.25] From: WongErnuz To: Date: Wed, 6 Aug 2008 15:19:30 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Aug 2008 07:19:30.0853 (UTC) FILETIME=[C4C51550:01C8F794] Subject: [Hipsec] Question about multiple HIs for a single host X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: multipart/mixed; boundary="===============2056618350==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --===============2056618350== Content-Type: multipart/alternative; boundary="_5b3c61c4-a778-4815-af93-349b9a1105fb_" --_5b3c61c4-a778-4815-af93-349b9a1105fb_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi! I've been reading drafts on HIP and related papaers, and I kinda got the idea that it is OK for a single host to possess multiple HIs (is that really possible?). If so, I think there has to be a one-to-one binding relationship between a certain HI and a FQDN, otherwise, when a peer host needs to extract the sender's HI from the DNS according to the received FQDN to check the signature, wouldn't it be possible for the host to obtain multiple HIs all at once? (since the sender has many HIs itself) Therefore, how is the host supposed to know which one to use? If HIP RR contains HIT in addition to HI, the receiver can compare the HIT received in the header with each of the HITs obtained from DNS to find the corresponding HI the sender is currently using with the FQDN. However, since HIT provision is optional in DNS, I think it is necessary to recommend each host use a unique HI for a particular FQDN to avoid the one-to-many mapping. Am I right? I'm sorry if the quesiton seems stupid; I'm new on this... _________________________________________________________________ 快来看看这些猫咪有多逗，爆笑！ http://cnweb.search.live.com/video/results.aspx?q=%E5%8F%AF%E7%88%B1%E7%8C%AB%E5%92%AA&Form=MEVHAA --_5b3c61c4-a778-4815-af93-349b9a1105fb_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hi!

I've been reading drafts on HIP and related papaers, and I kinda got the idea that it is OK for a single host to possess multiple HIs (is that really possible?). If so, I think there has to be a one-to-one binding relationship between a certain HI and a FQDN, otherwise, when a peer host needs to extract the sender's HI from the DNS according to the received FQDN to check the signature, wouldn't it be possible for the host to obtain multiple HIs all at once? (since the sender has many HIs itself) Therefore, how is the host supposed to know which one to use? If HIP RR contains HIT in addition to HI, the receiver can compare the HIT received in the header with each of the HITs obtained from DNS to find the corresponding HI the sender is currently using with the FQDN. However, since HIT provision is optional in DNS, I think it is necessary to recommend each host use a unique HI for a particular FQDN to avoid the one-to-many mapping. Am I right?

I'm sorry if the quesiton seems stupid; I'm new on this...

使用新一代 Windows Live Messenger 轻松交流和共享！立刻下载！ --_5b3c61c4-a778-4815-af93-349b9a1105fb_-- --===============2056618350== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec --===============2056618350==-- From hipsec-bounces@ietf.org Wed Aug 6 00:49:28 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5767A3A6916; Wed, 6 Aug 2008 00:49:28 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62E33A6916 for ; Wed, 6 Aug 2008 00:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.405 X-Spam-Level: ** X-Spam-Status: No, score=2.405 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLQGncaPFvzq for ; Wed, 6 Aug 2008 00:49:25 -0700 (PDT) Received: from bay0-omc1-s32.bay0.hotmail.com (bay0-omc1-s32.bay0.hotmail.com [65.54.246.104]) by core3.amsl.com (Postfix) with ESMTP id EB4853A67AD for ; Wed, 6 Aug 2008 00:49:25 -0700 (PDT) Received: from BAY117-W38 ([207.46.8.73]) by bay0-omc1-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 00:49:22 -0700 Message-ID: X-Originating-IP: [218.2.216.25] From: WongErnuz To: Date: Wed, 6 Aug 2008 15:49:22 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Aug 2008 07:49:22.0739 (UTC) FILETIME=[F0D13030:01C8F798] Subject: [Hipsec] Question about multiple HIs for a single host X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: multipart/mixed; boundary="===============1372469054==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --===============1372469054== Content-Type: multipart/alternative; boundary="_bba77f9f-32d9-4cbd-b5dc-023c4960af5f_" --_bba77f9f-32d9-4cbd-b5dc-023c4960af5f_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi! I've been reading drafts on HIP and related papaers, and I kinda got the idea that it is OK for a single host to possess multiple HIs (is that really possible?). If so, I think there has to be a one-to-one binding relationship between a certain HI and a FQDN, otherwise, when a peer host needs to extract the sender's HI from the DNS according to the received FQDN to check the signature, wouldn't it be possible for the host to obtain multiple HIs all at once? (since the sender has many HIs itself) Therefore, how is the host supposed to know which one to use? If HIP RR contains HIT in addition to HI, the receiver can compare the HIT received in the header with each of the HITs obtained from DNS to find the corresponding HI the sender is currently using with the FQDN. However, since HIT provision is optional in DNS, I think it is necessary to recommend each host use a unique HI for a particular FQDN to avoid the one-to-many mapping. Am I right? I'm sorry if the quesiton seems stupid; I'm new on this... _________________________________________________________________ 看MSN史诗巨片，票选人气角色，赢取PSP等诸多好礼！ http://im.msn.cn/ --_bba77f9f-32d9-4cbd-b5dc-023c4960af5f_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hi!

I've been reading drafts on HIP and related papaers, and I kinda got the idea that it is OK for a single host to possess multiple HIs (is that really possible?). If so, I think there has to be a one-to-one binding relationship between a certain HI and a FQDN, otherwise, when a peer host needs to extract the sender's HI from the DNS according to the received FQDN to check the signature, wouldn't it be possible for the host to obtain multiple HIs all at once? (since the sender has many HIs itself) Therefore, how is the host supposed to know which one to use? If HIP RR contains HIT in addition to HI, the receiver can compare the HIT received in the header with each of the HITs obtained from DNS to find the corresponding HI the sender is currently using with the FQDN. However, since HIT provision is optional in DNS, I think it is necessary to recommend each host use a unique HI for a particular FQDN to avoid the one-to-many mapping. Am I right?

I'm sorry if the quesiton seems stupid; I'm new on this...

一点即聊，MSN推出新功能“点我！” 马上试试！ --_bba77f9f-32d9-4cbd-b5dc-023c4960af5f_-- --===============1372469054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec --===============1372469054==-- From hipsec-bounces@ietf.org Wed Aug 6 00:49:46 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837223A6960; Wed, 6 Aug 2008 00:49:46 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682F23A6960 for ; Wed, 6 Aug 2008 00:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdaQaCGHjYYK for ; Wed, 6 Aug 2008 00:49:44 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 603583A68A1 for ; Wed, 6 Aug 2008 00:49:44 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E53271EF70C; Wed, 6 Aug 2008 10:50:13 +0300 (EEST) Received: from despair.unknown.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id AA1FE1EF297; Wed, 6 Aug 2008 10:50:13 +0300 (EEST) Message-ID: <489957B5.6090505@nomadiclab.com> Date: Wed, 06 Aug 2008 10:50:13 +0300 From: Jan Mikael Melen User-Agent: Thunderbird 2.0.0.7pre (X11/20080131) MIME-Version: 1.0 To: WongErnuz References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: hipsec@ietf.org Subject: Re: [Hipsec] Question about multiple HIs for a single host X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org SGksCgoKWWVzIGl0IGlzIHBvc3NpYmxlIHRvIHBvc3NlcyBtdWx0aXBsZSBISXMuIElmIEkgdW5k ZXJzdG9vZCB5b3VyIGNvbmNlcm4KY29ycmVjdGx5IHRoZW4gSSdsbCBqdXN0IHdhbnQgdG8gY29y cmVjdCBvbmUgd3JvbmcgYXNzdW1wdGlvbiB5b3UgaGF2ZQptYWRlLiBUaGUgcmVzcG9uZGVyIChw ZWVyKSBnZXRzIGJvdGggdGhlIGluaXRpYXRvcidzIEhJIGFuZCBISVQgaW4gdGhlCkkyIG1lc3Nh Z2Ugc28gaXQgdGhlcmUgaXMgbm8gbmVlZCB0byBleHRyYWN0IHRoZSBISSBmcm9tIHRoZSBETlMg aW4Kb3JkZXIgdG8gdmVyaWZ5IHRoZSBzaWduYXR1cmUuIFdoZW4gdGhlIEkyIGlzIHJlY2VpdmVk IHRoZSByZXNwb25kZXIKdmVyaWZpZXMgdGhhdCB0aGUgSElUIG1hdGNoZXMgd2l0aCB0aGUgSEkg cmVjZWl2ZWQgaW4gdGhlIHBhY2tldC4KClJlZ2FyZHMsCkphbgoKCldvbmdFcm51eiB3cm90ZToK PiBIaSEKPgo+IEkndmUgYmVlbiByZWFkaW5nIGRyYWZ0cyBvbiBISVAgYW5kIHJlbGF0ZWQgcGFw YWVycywgYW5kIEkga2luZGEgZ290Cj4gdGhlIGlkZWEgdGhhdCBpdCBpcyBPSyBmb3IgYSBzaW5n bGUgaG9zdCB0byBwb3NzZXNzIG11bHRpcGxlIEhJcyAoaXMKPiB0aGF0IHJlYWxseSBwb3NzaWJs ZT8pLiBJZiBzbywgSSB0aGluayB0aGVyZSBoYXMgdG8gYmUgYSBvbmUtdG8tb25lCj4gYmluZGlu ZyByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIGNlcnRhaW4gSEkgYW5kIGEgRlFETiwgb3RoZXJ3aXNl LCB3aGVuCj4gYSBwZWVyIGhvc3QgbmVlZHMgdG8gZXh0cmFjdCB0aGUgc2VuZGVyJ3MgSEkgZnJv bSB0aGUgRE5TIGFjY29yZGluZyB0bwo+IHRoZSByZWNlaXZlZCBGUUROIHRvIGNoZWNrIHRoZSBz aWduYXR1cmUsIHdvdWxkbid0IGl0IGJlIHBvc3NpYmxlIGZvcgo+IHRoZSBob3N0IHRvIG9idGFp biBtdWx0aXBsZSBISXMgYWxsIGF0IG9uY2U/IChzaW5jZSB0aGUgc2VuZGVyIGhhcwo+IG1hbnkg SElzIGl0c2VsZikgVGhlcmVmb3JlLCBob3cgaXMgdGhlIGhvc3Qgc3VwcG9zZWQgdG8ga25vdyB3 aGljaCBvbmUKPiB0byB1c2U/IElmIEhJUCBSUiBjb250YWlucyBISVQgaW4gYWRkaXRpb24gdG8g SEksIHRoZSByZWNlaXZlciBjYW4KPiBjb21wYXJlIHRoZSBISVQgcmVjZWl2ZWQgaW4gdGhlIGhl YWRlciB3aXRoIGVhY2ggb2YgdGhlIEhJVHMgb2J0YWluZWQKPiBmcm9tIEROUyB0byBmaW5kIHRo ZSBjb3JyZXNwb25kaW5nIEhJIHRoZSBzZW5kZXIgaXMgY3VycmVudGx5IHVzaW5nCj4gd2l0aCB0 aGUgRlFETi4gSG93ZXZlciwgc2luY2UgSElUIHByb3Zpc2lvbiBpcyBvcHRpb25hbCBpbiBETlMs IEkKPiB0aGluayBpdCBpcyBuZWNlc3NhcnkgdG8gcmVjb21tZW5kIGVhY2ggaG9zdCB1c2UgYSB1 bmlxdWUgSEkgZm9yIGEKPiBwYXJ0aWN1bGFyIEZRRE4gdG8gYXZvaWQgdGhlIG9uZS10by1tYW55 IG1hcHBpbmcuIEFtIEkgcmlnaHQ/Cj4KPiBJJ20gc29ycnkgaWYgdGhlIHF1ZXNpdG9uIHNlZW1z IHN0dXBpZDsgSSdtIG5ldyBvbiB0aGlzLi4uCj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiDKudPD0MLS u7T6IFdpbmRvd3MgTGl2ZSBNZXNzZW5nZXIgx+HLyb27wfe6zbmyz+2joSDBor/Mz8LU2KOhCj4g PGh0dHA6Ly9pbS5saXZlLmNuLz4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gSGlwc2VjIG1haWxpbmcgbGlzdAo+ IEhpcHNlY0BpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aGlwc2VjCj4gICAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkhpcHNlYyBtYWlsaW5nIGxpc3QKSGlwc2VjQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaGlwc2VjCg== From hipsec-bounces@ietf.org Thu Aug 14 10:41:09 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B625A3A6957; Thu, 14 Aug 2008 10:41:09 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E59D3A6957 for ; Thu, 14 Aug 2008 10:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A66ei0TUfq6E for ; Thu, 14 Aug 2008 10:41:07 -0700 (PDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by core3.amsl.com (Postfix) with ESMTP id 342283A6868 for ; Thu, 14 Aug 2008 10:41:06 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id m7EHf880013528 for ; Thu, 14 Aug 2008 20:41:08 +0300 Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 26385-120-19 for ; Thu, 14 Aug 2008 20:41:08 +0300 (EEST) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id m7EHesFn013237 for ; Thu, 14 Aug 2008 20:40:54 +0300 Date: Thu, 14 Aug 2008 20:40:54 +0300 (EEST) From: Lauri Silvennoinen To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [Hipsec] HIP Registration Extension (fwd) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hi all, I asked a few questions related to the HIP Registration Extension back on April, but I think I never got an answer to these questions. The draft is now known as RFC 5203, but the issues remain unanswered. So I send my previous mail again, hoping to get an answer this time. In addition to the issues presented below, I would like to propose a new Failure Type to be used in the REG_FAILED parameter. We have currently two Failure Types defined: Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable Now, when the server is able to provide multiple services and some of these services cannot co-exist i.e. a single requester cannot be registered to these services simultaneously, how does the server respond to a registration attempt? For example, if a server is able to provide both rendezvous service and full relay for HIP packets service (used in ICE), a single requester cannot be allowed to register to both of these services without canceling the previously granted service first. For this type of situation, I suggest a new Failure Type: Failure Type Reason ------------ -------------------------------------------- 2 Cancellation required The other possibility would be to just silently overwrite the previous registration. Best regards, Lauri ---------- Forwarded message ---------- Date: Mon, 14 Apr 2008 16:30:40 +0300 (EEST) From: Lauri Silvennoinen Hi, I am implementing / improving the existing implementation of the HIP Registration Extension for InfraHIP project (HIPL). I have a few questions concerning draft-ietf-hip-registration-02: 1) How does a registrar announce that it is capable of providing multiple services with different lifetimes? In Section 3.1 it is said that "a registrar SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges." The REG_INFO parameter, however, is of the following form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | Reg Type #n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I.e. it has single "Min Lifetime" and "Max Lifetime" values. The issue would be solved if the registrar could include multiple REG_INFO parameters in the R1 packets, but nothing is said about multiple REG_INFOs in the draft. 2) How to handle REG_REQUEST, REG_RESPONSE and REG_FAILED parameters that have redundant services? These parameters are of the following form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | Reg Type #n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Now, what happens if, say, both "Reg Type #1" and "Reg Type #2" are of type RVS? Not that it would make any sense to build such parameters, but the hosts should be ready to handle such parameters. 3) What happens if registration cancellation does not succeed? In Section 5 it is said: "A zero lifetime is reserved for canceling purposes. Requesting a zero lifetime for a registration type equals to canceling the registration of that type. A requester MAY cancel a registration before it expires by sending a REG_REQ to the registrar with a zero lifetime. A registrar SHOULD respond and grant a registration with a zero lifetime. A registrar (and an attached service) MAY cancel a registration before it expires, at its own discretion. However, if it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all registered requesters." Thus if the requester wants to cancel a service it sends a REG_REQUEST parameter with zero lifetime to which the registrar should answer with a REG_RESPONSE with zero lifetime respectively. But what happens if the registrar is unable to cancel the registration due to transient conditions or some other reason? Does the registrar just remain silent or send a REG_FAILED? Thanks, Lauri _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Aug 18 09:55:36 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B843A6D49; Mon, 18 Aug 2008 09:55:36 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF583A6D49 for ; Mon, 18 Aug 2008 09:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eARVeEi1kf3O for ; Mon, 18 Aug 2008 09:55:33 -0700 (PDT) Received: from deprox.docomolab-euro.com (deprox.docomolab-euro.com [212.119.9.186]) by core3.amsl.com (Postfix) with ESMTP id 1ADF83A6932 for ; Mon, 18 Aug 2008 09:55:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deprox.docomolab-euro.com (Postfix) with ESMTP id 3AE7617042; Mon, 18 Aug 2008 18:55:41 +0200 (CEST) Received: from deprox.docomolab-euro.com ([127.0.0.1]) by localhost (deprox.docomolab-euro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHLyYnBoSLCJ; Mon, 18 Aug 2008 18:55:38 +0200 (CEST) Received: from DEMAIL.docomolab-euro.com (demail.docomolab-euro.com [172.27.20.3]) by deprox.docomolab-euro.com (Postfix) with ESMTP; Mon, 18 Aug 2008 18:55:38 +0200 (CEST) Received: from [192.168.99.29] ([192.168.99.29]) by DEMAIL.docomolab-euro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 18:55:34 +0200 Message-ID: <48A9A97D.6010701@googlemail.com> Date: Mon, 18 Aug 2008 18:55:25 +0200 From: Julien Laganier User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Lauri Silvennoinen References: In-Reply-To: X-OriginalArrivalTime: 18 Aug 2008 16:55:36.0367 (UTC) FILETIME=[3C60F3F0:01C90153] Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Registration Extension (fwd) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hi Lauri, Lauri Silvennoinen wrote: > Hi all, > > I asked a few questions related to the HIP Registration Extension back > on April, but I think I never got an answer to these questions. The > draft is now known as RFC 5203, but the issues remain unanswered. So I > send my previous mail again, hoping to get an answer this time. Sorry for not answering before. Better later than never :) Some comments inlined below: > In addition to the issues presented below, I would like to propose a new > Failure Type to be used in the REG_FAILED parameter. We have currently > two Failure Types defined: > > Failure Type Reason > ------------ -------------------------------------------- > 0 Registration requires additional credentials > 1 Registration type unavailable > > Now, when the server is able to provide multiple services and some of > these services cannot co-exist i.e. a single requester cannot be > registered to these services simultaneously, how does the server respond > to a registration attempt? > > For example, if a server is able to provide both rendezvous service and > full relay for HIP packets service (used in ICE), a single requester > cannot be allowed to register to both of these services without > canceling the previously granted service first. Ok for the usecase, but shouldn't this be considered as an error from the MN. The MN implementation supposedly knows that RVS and ICE are exclusive, and shouldn't try to register for both at the same time on the same node. > For this type of situation, I suggest a new Failure Type: > > Failure Type Reason > ------------ -------------------------------------------- > 2 Cancellation required In that case, wouldn't be needed to signal to the MN which types of registration have to be canceled for the requested one to be granted? > The other possibility would be to just silently overwrite the previous > registration. Silent overwriting wouldn't be good. The registrar should grant the new registration and cancel the old one (see below excerpt from Sec. 5 of RFC 5203), or vice versa: A registrar (and an attached service) MAY cancel a registration before it expires, at its own discretion. However, if it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all registered requesters. [...] > 1) How does a registrar announce that it is capable of providing multiple > services with different lifetimes? When we wrote that spec we didn't foresee such a usecase. The lifetime was on per-server basis, i.e. the time the server is willing to provide registrations, the time it expects to stay up, etc. > In Section 3.1 it is said that "a registrar SHOULD include a REG_INFO > parameter in the R1 packets it sends during all base exchanges." The > REG_INFO parameter, however, is of the following form: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... | Reg Type #n | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I.e. it has single "Min Lifetime" and "Max Lifetime" values. The issue > would be solved if the registrar could include multiple REG_INFO > parameters in the R1 packets, but nothing is said about multiple > REG_INFOs in the draft. Thus an additional specification would be required it seems. > 2) How to handle REG_REQUEST, REG_RESPONSE and REG_FAILED parameters that > have redundant services? These parameters are of the following form: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... | Reg Type #n | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Now, what happens if, say, both "Reg Type #1" and "Reg Type #2" are of > type RVS? Not that it would make any sense to build such parameters, > but > the hosts should be ready to handle such parameters. I consider this as broken behavior from the registrar side, but anyway it seems the MN could simply ignore duplicates Reg types with no harm. > 3) What happens if registration cancellation does not succeed? In Section > 5 it is said: > > "A zero lifetime is reserved for canceling purposes. Requesting a zero > lifetime for a registration type equals to canceling the registration > of that type. A requester MAY cancel a registration before it expires > by sending a REG_REQ to the registrar with a zero lifetime. A > registrar SHOULD respond and grant a registration with a zero lifetime. > A registrar (and an attached service) MAY cancel a registration before > it expires, at its own discretion. However, if it does so, it SHOULD > send a REG_RESPONSE with a zero lifetime to all registered requesters." > > Thus if the requester wants to cancel a service it sends a REG_REQUEST > parameter with zero lifetime to which the registrar should answer with > a REG_RESPONSE with zero lifetime respectively. But what happens if the > registrar is unable to cancel the registration due to transient > conditions or some other reason? Does the registrar just remain silent > or send a REG_FAILED? Again that would be broken behavior from the registrar side, we have a SHOULD there. If it doesn't do so, then it either doesn't reply or send REG_FAILED, in any case the MN would not be be mistaken in believing the cancellation was successful. Do you think more text is needed? --julien _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Aug 18 13:23:52 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6460728C1FB; Mon, 18 Aug 2008 13:23:52 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89BF428C1FA for ; Mon, 18 Aug 2008 13:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UowaX1ywmhgx for ; Mon, 18 Aug 2008 13:23:50 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 0EA063A6D5B for ; Mon, 18 Aug 2008 13:23:50 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 36E441EF1DA; Mon, 18 Aug 2008 23:23:56 +0300 (EEST) Received: from despair.unknown.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id D7F491EF1D9; Mon, 18 Aug 2008 23:23:55 +0300 (EEST) Message-ID: <48A9DA5A.1050403@nomadiclab.com> Date: Mon, 18 Aug 2008 23:23:54 +0300 From: Jan Mikael Melen User-Agent: Thunderbird 2.0.0.7pre (X11/20080131) MIME-Version: 1.0 To: hipsec@ietf.org, hipsec-rg@listserv.cybertrust.com X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Hipsec] hip4inter.net HIP daemon code relicensed X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hello, As you might know, previously Host Identity Protocol (HIP) daemon made = by hip4inter.net has been published under Ericsson Public License (a = derivate from Mozilla Public License), but now the license has been = changed and the new license is FreeBSD license or =932-clause BSD license= =94 = if you like to call it that. The new code can be downloaded from = http://www.hip4inter.net/download/download.php On Behalf of whole hip4inter.net team Jan Melen _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Aug 19 10:35:53 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49F23A6A2B; Tue, 19 Aug 2008 10:35:53 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A603D3A68C4 for ; Tue, 19 Aug 2008 10:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kqNlsaYjivr for ; Tue, 19 Aug 2008 10:35:51 -0700 (PDT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by core3.amsl.com (Postfix) with ESMTP id 676573A6827 for ; Tue, 19 Aug 2008 10:35:51 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id m7JHYNCj029008; Tue, 19 Aug 2008 20:34:23 +0300 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 21585-214-32; Tue, 19 Aug 2008 20:34:22 +0300 (EEST) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id m7JHWxVR027826; Tue, 19 Aug 2008 20:32:59 +0300 Date: Tue, 19 Aug 2008 20:32:59 +0300 (EEST) From: Lauri Silvennoinen To: Julien Laganier In-Reply-To: <48A9A97D.6010701@googlemail.com> Message-ID: References: <48A9A97D.6010701@googlemail.com> MIME-Version: 1.0 X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Registration Extension X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org On Mon, 18 Aug 2008, Julien Laganier wrote: Hi Julien, > Hi Lauri, > Some comments inlined below: > >> ... > > Ok for the usecase, but shouldn't this be considered as an error from the MN. > The MN implementation supposedly knows that RVS and ICE are exclusive, and > shouldn't try to register for both at the same time on the same node. It can and should be considered as an error from the Requester. However, this does not mean that the Requester cannot send such a message. I'm mostly concerned about the server implementation in all of the issues. Thus the question is: how does the server respond to a registration attempt having services that cannot co-exist. RFC 5203 does not provide instructions for this. Are you suggesting that the server should just silently drop such a request? If so, this should be put in clear text into the RFC. >> ... > > In that case, wouldn't be needed to signal to the MN which types of > registration have to be canceled for the requested one to be granted? > This would be even better, but then we would need individual Failure Types for each registration that needs to be cancelled. So instead of Failure Type Reason ------------ -------------------------------------------- 2 Cancellation required we would have for example: Failure Type Reason ------------ -------------------------------------------- 101 RVS Cancellation required 102 HIP RELAY Cancellation required 103 ... ... This could get too complicated when the number of HIP services (and HIP service related specifications) increases. So I would stick to the single "Cancellation required" value instead and let it be local policy at the Requester to know which services cannot co-exist. Either way, isn't it better to signal "Cancellation required" than "Registration requires additional credentials" or "Registration type unavailable" (or to remain silent) in this case? >> ... >> but nothing is said about multiple REG_INFOs in the draft. > > Thus an additional specification would be required it seems. Yes. >> 2) How to handle REG_REQUEST, REG_RESPONSE and REG_FAILED parameters that >> have redundant services? These parameters are of the following form: >> ... > > I consider this as broken behavior from the registrar side, but anyway it > seems the MN could simply ignore duplicates Reg types with no harm. Broken behavior yes, but again, the RFC does not state in clear text how to handle such a case. If a REG_REQUEST has redundant services, then it's broken behavior at the Requester side. If a REG_RESPONSE or a REG_FAILED has redundant services, then it's broken behavior at the Registrar side. I suggest the following: The REG_REQUEST case i.e. the client has requested redundant services. The server should not allow any broken behavior from the client. Therefore the whole packet having redundant services should be just silently dropped. Note that the process of handling the REG_REQUEST parameter at the server involves the creation of some kind of registration state and that this creation can be time and resource consuming. The REG_RESPONSE and REG_FAILED cases i.e. the server has granted/denied redundant services. This should be a local policy issue at the client. If the server shows broken behavior, the client can always choose to use another server. >> 3) What happens if registration cancellation does not succeed? In Section >> 5 it is said: >> ... > > Again that would be broken behavior from the registrar side, we have a SHOULD > there. If it doesn't do so, then it either doesn't reply or send REG_FAILED, > in any case the MN would not be be mistaken in believing the cancellation was > successful. Perhaps this could be clarified by saying "The Requester cannot assume that the cancellation was successful until it receives a REG_RESPONSE with a zero lifetime." > Do you think more text is needed? Yes, at least for the "Reg Types" with different "Min Lifetime" / "Max Lifetime" / "Lifetime" values. -Lauri _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Aug 19 10:49:04 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4606D28C15A; Tue, 19 Aug 2008 10:49:04 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBDE028C1EA for ; Tue, 19 Aug 2008 10:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv2HnUZN3-+L for ; Tue, 19 Aug 2008 10:49:00 -0700 (PDT) Received: from deprox.docomolab-euro.com (deprox.docomolab-euro.com [212.119.9.186]) by core3.amsl.com (Postfix) with ESMTP id 6E6613A6D40 for ; Tue, 19 Aug 2008 10:48:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deprox.docomolab-euro.com (Postfix) with ESMTP id C9F8317024; Tue, 19 Aug 2008 19:48:04 +0200 (CEST) Received: from deprox.docomolab-euro.com ([127.0.0.1]) by localhost (deprox.docomolab-euro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSRJuumMKDNG; Tue, 19 Aug 2008 19:47:57 +0200 (CEST) Received: from DEMAIL.docomolab-euro.com (demail.docomolab-euro.com [172.27.20.3]) by deprox.docomolab-euro.com (Postfix) with ESMTP; Tue, 19 Aug 2008 19:47:56 +0200 (CEST) Received: from [192.168.99.36] ([192.168.99.36]) by DEMAIL.docomolab-euro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 19:47:54 +0200 Message-ID: <48AB074E.1000604@googlemail.com> Date: Tue, 19 Aug 2008 19:47:58 +0200 From: Julien Laganier User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Lauri Silvennoinen References: <48A9A97D.6010701@googlemail.com> In-Reply-To: X-OriginalArrivalTime: 19 Aug 2008 17:47:54.0598 (UTC) FILETIME=[B552C060:01C90223] Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Registration Extension X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hi Lauri, Some more thougths... Lauri Silvennoinen wrote: > On Mon, 18 Aug 2008, Julien Laganier wrote: >> >> Ok for the usecase, but shouldn't this be considered as an error from >> the MN. The MN implementation supposedly knows that RVS and ICE are >> exclusive, and shouldn't try to register for both at the same time on >> the same node. > > It can and should be considered as an error from the Requester. However, > this does not mean that the Requester cannot send such a message. I'm > mostly concerned about the server implementation in all of the issues. > Thus the question is: how does the server respond to a registration > attempt having services that cannot co-exist. RFC 5203 does not provide > instructions for this. Are you suggesting that the server should just > silently drop such a request? If so, this should be put in clear text > into the RFC. I think since the RFC allows the server to cancel the earlier registration (sending >>> ... >> >> In that case, wouldn't be needed to signal to the MN which types of >> registration have to be canceled for the requested one to be granted? >> > > This would be even better, but then we would need individual Failure Types > for each registration that needs to be cancelled. So instead of > > Failure Type Reason > ------------ -------------------------------------------- > 2 Cancellation required > > we would have for example: > > Failure Type Reason > ------------ -------------------------------------------- > 101 RVS Cancellation required > 102 HIP RELAY Cancellation required > 103 ... > ... > > This could get too complicated when the number of HIP services (and HIP > service related specifications) increases. So I would stick to the > single "Cancellation required" value instead and let it be local policy > at the Requester to know which services cannot co-exist. Either way, > isn't it better to signal "Cancellation required" than "Registration > requires additional credentials" or "Registration type unavailable" (or > to remain silent) in this case? > >>> ... but nothing is said about multiple REG_INFOs in the draft. >> >> Thus an additional specification would be required it seems. > > Yes. > >>> 2) How to handle REG_REQUEST, REG_RESPONSE and REG_FAILED parameters >>> that >>> have redundant services? These parameters are of the following form: >>> ... >> >> I consider this as broken behavior from the registrar side, but anyway >> it seems the MN could simply ignore duplicates Reg types with no harm. > > Broken behavior yes, but again, the RFC does not state in clear text how > to handle such a case. If a REG_REQUEST has redundant services, then > it's broken behavior at the Requester side. If a REG_RESPONSE or a > REG_FAILED has redundant services, then it's broken behavior at the > Registrar side. I suggest the following: > > The REG_REQUEST case i.e. the client has requested redundant services. > The server should not allow any broken behavior from the client. > Therefore the whole packet having redundant services should be just > silently dropped. Note that the process of handling the REG_REQUEST > parameter at the server involves the creation of some kind of > registration state and that this creation can be time and resource > consuming. > > The REG_RESPONSE and REG_FAILED cases i.e. the server has granted/denied > redundant services. This should be a local policy issue at the client. > If the server shows broken behavior, the client can always choose to use > another server. > >>> 3) What happens if registration cancellation does not succeed? In >>> Section >>> 5 it is said: >>> ... >> >> Again that would be broken behavior from the registrar side, we have a >> SHOULD there. If it doesn't do so, then it either doesn't reply or >> send REG_FAILED, in any case the MN would not be be mistaken in >> believing the cancellation was successful. > > Perhaps this could be clarified by saying "The Requester cannot assume > that the cancellation was successful until it receives a REG_RESPONSE > with a zero lifetime." > >> Do you think more text is needed? > > Yes, at least for the "Reg Types" with different "Min Lifetime" / "Max > Lifetime" / "Lifetime" values. > > -Lauri _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Aug 19 10:57:46 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835193A68C3; Tue, 19 Aug 2008 10:57:46 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1227A3A6AB0 for ; Tue, 19 Aug 2008 10:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Qmkadp+axjS for ; Tue, 19 Aug 2008 10:57:44 -0700 (PDT) Received: from deprox.docomolab-euro.com (deprox.docomolab-euro.com [212.119.9.186]) by core3.amsl.com (Postfix) with ESMTP id 72EB73A68DC for ; Tue, 19 Aug 2008 10:57:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deprox.docomolab-euro.com (Postfix) with ESMTP id 8562117028; Tue, 19 Aug 2008 19:57:34 +0200 (CEST) Received: from deprox.docomolab-euro.com ([127.0.0.1]) by localhost (deprox.docomolab-euro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnPolbAHMPiE; Tue, 19 Aug 2008 19:57:31 +0200 (CEST) Received: from DEMAIL.docomolab-euro.com (demail.docomolab-euro.com [172.27.20.3]) by deprox.docomolab-euro.com (Postfix) with ESMTP; Tue, 19 Aug 2008 19:57:31 +0200 (CEST) Received: from [192.168.99.36] ([192.168.99.36]) by DEMAIL.docomolab-euro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 19:57:29 +0200 Message-ID: <48AB098D.80704@googlemail.com> Date: Tue, 19 Aug 2008 19:57:33 +0200 From: Julien Laganier User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Lauri Silvennoinen References: <48A9A97D.6010701@googlemail.com> In-Reply-To: X-OriginalArrivalTime: 19 Aug 2008 17:57:29.0521 (UTC) FILETIME=[0C010A10:01C90225] Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Registration Extension X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org [sorry for resent, wronly hit CTRL+ENTER] Hi Lauri, Some more thougths... Lauri Silvennoinen wrote: > On Mon, 18 Aug 2008, Julien Laganier wrote: >> >> Ok for the usecase, but shouldn't this be considered as an error from >> the MN. The MN implementation supposedly knows that RVS and ICE are >> exclusive, and shouldn't try to register for both at the same time on >> the same node. > > It can and should be considered as an error from the Requester. However, > this does not mean that the Requester cannot send such a message. I'm > mostly concerned about the server implementation in all of the issues. > Thus the question is: how does the server respond to a registration > attempt having services that cannot co-exist. RFC 5203 does not provide > instructions for this. Are you suggesting that the server should just > silently drop such a request? If so, this should be put in clear text > into the RFC. I think since the RFC allows the server to cancel the earlier (incompatible) registration, then it should do that, and grant the new one: A registrar (and an attached service) MAY cancel a registration before it expires, at its own discretion. However, if it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all registered requesters. >>> ... >> >> In that case, wouldn't be needed to signal to the MN which types of >> registration have to be canceled for the requested one to be granted? >> > > This would be even better, but then we would need individual Failure Types > for each registration that needs to be cancelled. So instead of > > Failure Type Reason > ------------ -------------------------------------------- > 2 Cancellation required > > we would have for example: > > Failure Type Reason > ------------ -------------------------------------------- > 101 RVS Cancellation required > 102 HIP RELAY Cancellation required > 103 ... > ... > This could get too complicated when the number of HIP services (and HIP > service related specifications) increases. So I would stick to the > single "Cancellation required" value instead and let it be local policy > at the Requester to know which services cannot co-exist. Either way, > isn't it better to signal "Cancellation required" than "Registration > requires additional credentials" or "Registration type unavailable" (or > to remain silent) in this case? Defining new failure types wouldn't be good. I was thinking more about piggybacking to the REG_FAILED for "cancellation required" with a REG_TYPES_TO_CANCEL parameter containing the registrations types that shall be cancelled before the requested registration is granted. But that seems to complex. Since this is somehow an error case from the requester I think we should do as I suggested earlier, i.e. the registrar signal that incompatible registations were cancelled, and accpet the new one. >>> ... but nothing is said about multiple REG_INFOs in the draft. >> >> Thus an additional specification would be required it seems. > > Yes. I am not sure it is required to indicate different lifetimes for different services though. If you really want to handle various lifetime, you can get the same result by announcing the min lifetime of services you're offering for all services. >>> 2) How to handle REG_REQUEST, REG_RESPONSE and REG_FAILED parameters >>> that >>> have redundant services? These parameters are of the following form: >>> ... >> >> I consider this as broken behavior from the registrar side, but anyway >> it seems the MN could simply ignore duplicates Reg types with no harm. > > Broken behavior yes, but again, the RFC does not state in clear text how > to handle such a case. If a REG_REQUEST has redundant services, then > it's broken behavior at the Requester side. If a REG_RESPONSE or a > REG_FAILED has redundant services, then it's broken behavior at the > Registrar side. I suggest the following: > > The REG_REQUEST case i.e. the client has requested redundant services. > The server should not allow any broken behavior from the client. > Therefore the whole packet having redundant services should be just > silently dropped. I disagree. If we follow the "be conservative in what you send, liberal in what you accept", a peer receiving duplicate registration types should just ignore the duplicated occurrences. > Note that the process of handling the REG_REQUEST > parameter at the server involves the creation of some kind of > registration state and that this creation can be time and resource > consuming. > > The REG_RESPONSE and REG_FAILED cases i.e. the server has granted/denied > redundant services. This should be a local policy issue at the client. > If the server shows broken behavior, the client can always choose to use > another server. > >>> 3) What happens if registration cancellation does not succeed? In >>> Section >>> 5 it is said: >>> ... >> >> Again that would be broken behavior from the registrar side, we have a >> SHOULD there. If it doesn't do so, then it either doesn't reply or >> send REG_FAILED, in any case the MN would not be be mistaken in >> believing the cancellation was successful. > > Perhaps this could be clarified by saying "The Requester cannot assume > that the cancellation was successful until it receives a REG_RESPONSE > with a zero lifetime." I think this is implicit in the specification, don't you think so? >> Do you think more text is needed? > > Yes, at least for the "Reg Types" with different "Min Lifetime" / "Max > Lifetime" / "Lifetime" values. As I said, not sure that's really needed for any usecase. And in case you really have a hard requirement to support that, you could configure different Registrars announcing different lifetimes w/ different HITs on the same node. That can be left to implementation. --julien _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Aug 20 11:16:30 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDD928C1A2; Wed, 20 Aug 2008 11:16:30 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2048628C1A2 for ; Wed, 20 Aug 2008 11:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFv2ssaWw6v9 for ; Wed, 20 Aug 2008 11:16:24 -0700 (PDT) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by core3.amsl.com (Postfix) with ESMTP id 9B4C63A6C50 for ; Wed, 20 Aug 2008 11:16:24 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id m7KIG4Ru029131; Wed, 20 Aug 2008 21:16:04 +0300 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 23402-232-40; Wed, 20 Aug 2008 21:16:03 +0300 (EEST) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id m7KI2bSQ023329; Wed, 20 Aug 2008 21:02:37 +0300 Date: Wed, 20 Aug 2008 21:02:37 +0300 (EEST) From: Lauri Silvennoinen To: Julien Laganier In-Reply-To: <48AB098D.80704@googlemail.com> Message-ID: References: <48A9A97D.6010701@googlemail.com> <48AB098D.80704@googlemail.com> MIME-Version: 1.0 X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Registration Extension X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hi Julien, On Tue, 19 Aug 2008, Julien Laganier wrote: > Hi Lauri, > Some more thougths... >> >> It can and should be considered as an error from the Requester. >> However, this does not mean that the Requester cannot send such a >> message. I'm mostly concerned about the server implementation in all >> of the issues. Thus the question is: how does the server respond to a >> registration attempt having services that cannot co-exist. RFC 5203 >> does not provide instructions for this. Are you suggesting that the >> server should just silently drop such a request? If so, this should be >> put in clear text into the RFC. > > I think since the RFC allows the server to cancel the earlier > (incompatible) registration, then it should do that, and grant the new > one: > > A registrar (and an attached service) MAY cancel a > registration before it expires, at its own discretion. However, if > it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all > registered requesters. This would be reasonable behavior from the server. However, this is not implicit in the RFC and in my opinion needs clarification. The paragraph from the RFC above talks about "sending a REG_RESPONSE with a zero lifetime to _all_ registered requesters". Because of the word "all" there, the paragraph gives the impression that the server decides to remove the whole service from the supported services' pool and thus signals to all its clients the new set of supported services. This is not what we want here. A server can support both RVS and full relay services at the same time but a single client cannot be registered to both these services simultaneously. Therefore, the server should send a REG_RESPONSE with a zero lifetime only to the client who sent the REG_REQUEST. Also, because "the registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets" the client will receive at least two packets in response to a sent REG_REQUEST in this case. The figure on [Page 3] is in conflict with this behavior. > Defining new failure types wouldn't be good. I was thinking more about > piggybacking to the REG_FAILED for "cancellation required" with a > REG_TYPES_TO_CANCEL parameter containing the registrations types that > shall be cancelled before the requested registration is granted. But > that seems to complex. Since this is somehow an error case from the > requester I think we should do as I suggested earlier, i.e. the > registrar signal that incompatible registations were cancelled, and > accpet the new one. This works but as I said earlier, at least two packets will be sent in response. With Failure Type "Cancellation required" this would not happen. Alternatively multiple REG_RESPONSEs could be allowed in one packet. > I am not sure it is required to indicate different lifetimes for > different services though. If you really want to handle various > lifetime, you can get the same result by announcing the min lifetime of > services you're offering for all services. This is confusing for the server administrator. If the server supports two services S1 and S2 with lifetime boundaries configured as: S1 min 30s max 120s S2 min 3600s max 86400s the server would then signal [S1, S2 (30 86400)] in REG_INFO, and so the administrator's configurations are not respected. Next, the client wants to register to service S2 for 3600 seconds and sends a REG_REQUEST [S2 (3600)]. The server then checks the lifetime boundaries for the service S2 again and sends a REG_RESPONSE [S2 (120)]. Yep, this works, but it is illogical to signal different lifetime boundaries than what are later granted. This issue could be easily fixed by allowing multiple REG_INFOs / REG_RESPONSEs / REG_REQUESTs in one packet or by altering the parameters' formats. >> The REG_REQUEST case i.e. the client has requested redundant services. >> The server should not allow any broken behavior from the client. >> Therefore the whole packet having redundant services should be just >> silently dropped. > > I disagree. If we follow the "be conservative in what you send, liberal > in what you accept", a peer receiving duplicate registration types > should just ignore the duplicated occurrences. Fair enough, but this should be said in the RFC. >> > Again that would be broken behavior from the registrar side, we have >> > a SHOULD there. If it doesn't do so, then it either doesn't reply or >> > send REG_FAILED, in any case the MN would not be be mistaken in >> > believing the cancellation was successful. >> >> Perhaps this could be clarified by saying "The Requester cannot assume >> that the cancellation was successful until it receives a REG_RESPONSE >> with a zero lifetime." > > I think this is implicit in the specification, don't you think so? Hmmm... The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. So are "the full implications understood and carefully weighed" when the server does not send a REG_RESPONSE? "Carefully weighing" for me means that the issue is thought over and written in the RFC. I'm not saying this is an important point, but if the RFC is to be revised, the following clarification wouldn't hurt: "The Requester SHOULD NOT assume that the cancellation was successful until it receives a REG_RESPONSE with a matching Reg Type and a zero lifetime." >> Yes, at least for the "Reg Types" with different "Min Lifetime" / "Max >> Lifetime" / "Lifetime" values. > > As I said, not sure that's really needed for any usecase. And in case > you really have a hard requirement to support that, you could configure > different Registrars announcing different lifetimes w/ different HITs on > the same node. That can be left to implementation. Good point, but this would increase the administrative work. -Lauri _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Aug 25 23:44:24 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F57928C0FE; Mon, 25 Aug 2008 23:44:24 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8545828C0FE for ; Mon, 25 Aug 2008 23:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+i-dnOEb90W for ; Mon, 25 Aug 2008 23:44:22 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 5B85F28C0FA for ; Mon, 25 Aug 2008 23:44:22 -0700 (PDT) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 111641F51F6 for ; Tue, 26 Aug 2008 09:44:19 +0300 (EEST) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by n2.nomadiclab.com (Postfix) with ESMTP id CFE8F1F5165 for ; Tue, 26 Aug 2008 09:44:18 +0300 (EEST) Message-ID: <48B3A642.9080608@nomadiclab.com> Date: Tue, 26 Aug 2008 09:44:18 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: hipsec@ietf.org X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Hipsec] draft-ietf-hip-nat-traversal-05-pre1 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hi all, There's a new pre-version of the HIP NAT traversal base draft available here: http://users.piuha.net/akeranen/drafts/draft-ietf-hip-nat-traversal-05-pre1.txt As I mentioned during the WG meeting at Dublin, this version contains a bunch of editorial fixes and some details that were missing from the 04 version. If you wish to review the NAT traversal draft, please use this version instead of the 04 version. Cheers, Ari _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Aug 26 02:51:53 2008 Return-Path: X-Original-To: hip-archive@lists.ietf.org Delivered-To: ietfarch-hip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52F63A6ABB; Tue, 26 Aug 2008 02:51:53 -0700 (PDT) X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2439428C0EF for ; Tue, 26 Aug 2008 02:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJnIj2Ds8Sx8 for ; Tue, 26 Aug 2008 02:51:50 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by core3.amsl.com (Postfix) with ESMTP id 2499A3A6A98 for ; Tue, 26 Aug 2008 02:51:49 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so1749853mue.9 for ; Tue, 26 Aug 2008 02:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=2AmPXXJxZi+eRiwmn1MEFmZXmxkFmbMY2h2RdBiaNAQ=; b=LHvlxt9yzOqEmH2jQBAIihTaEp5yVnDlBgnLncC4s6C+esgT8/Ce/46PgAnQRQWDsv GyGoAndfm9mkdYH9Bj3MqIuva7YqDMMLtuubZvgI4RD1bag9mbDs5qEOHCoTP2NwvThv T7e3e3QfU8hvxjlhuWqcR27M0NR9esFUVhmLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=WbyoTl3Weei6HPpphJcxvb0RKDaDRc4a5uTiI2fyej3LxkwG140aVkHluDjTG06KRu d9dsg+T9qY4V/wvAVx/axrDPJwO2EBfhPd4wKKN7Yj8tNL7vJRqB8+/nT+89LzEthGew GI1ZjZ9oQMkcUiUfmWpyozEI542Io9CaQd6Y0= Received: by 10.103.215.17 with SMTP id s17mr3606901muq.61.1219744309310; Tue, 26 Aug 2008 02:51:49 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id i5sm31862556mue.11.2008.08.26.02.51.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 26 Aug 2008 02:51:48 -0700 (PDT) To: Lauri Silvennoinen Date: Tue, 26 Aug 2008 11:51:48 +0200 User-Agent: KMail/1.9.9 References: <48AB098D.80704@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808261151.48590.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Registration Extension X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org On Wednesday 20 August 2008, Lauri Silvennoinen wrote: > Hi Julien, > > On Tue, 19 Aug 2008, Julien Laganier wrote: > > Hi Lauri, > > Some more thougths... > > > >> It can and should be considered as an error from the Requester. > >> However, this does not mean that the Requester cannot send such a > >> message. I'm mostly concerned about the server implementation in > >> all of the issues. Thus the question is: how does the server > >> respond to a registration attempt having services that cannot > >> co-exist. RFC 5203 does not provide instructions for this. Are you > >> suggesting that the server should just silently drop such a > >> request? If so, this should be put in clear text into the RFC. > > > > I think since the RFC allows the server to cancel the earlier > > (incompatible) registration, then it should do that, and grant the > > new one: > > > > A registrar (and an attached service) MAY cancel a > > registration before it expires, at its own discretion. However, > > if it does so, it SHOULD send a REG_RESPONSE with a zero lifetime > > to all registered requesters. > > This would be reasonable behavior from the server. However, this is > not implicit in the RFC and in my opinion needs clarification. The > paragraph from the RFC above talks about "sending a REG_RESPONSE with > a zero lifetime to _all_ registered requesters". Because of the word > "all" there, the paragraph gives the impression that the server > decides to remove the whole service from the supported services' pool > and thus signals to all its clients the new set of supported > services. > > This is not what we want here. A server can support both RVS and full > relay services at the same time but a single client cannot be > registered to both these services simultaneously. Therefore, the > server should send a REG_RESPONSE with a zero lifetime only to the > client who sent the REG_REQUEST. I do not see the 'all' part as being that problematic. The spec says a registration may be cancelled by the registrar, that seems sufficient for the usecase we're discussing here. > Also, because "the registrar MUST NOT include more than one > REG_RESPONSE parameter in its R2 or UPDATE packets" the client will > receive at least two packets in response to a sent REG_REQUEST in > this case. The figure on [Page 3] is in conflict with this behavior. Well, somehow these figures are informative only, the normative text is in Section 4. "Parameter Formats and Processing". > > Defining new failure types wouldn't be good. I was thinking more > > about piggybacking to the REG_FAILED for "cancellation required" > > with a REG_TYPES_TO_CANCEL parameter containing the registrations > > types that shall be cancelled before the requested registration is > > granted. But that seems to complex. Since this is somehow an error > > case from the requester I think we should do as I suggested > > earlier, i.e. the registrar signal that incompatible registations > > were cancelled, and accpet the new one. > > This works but as I said earlier, at least two packets will be sent > in response. With Failure Type "Cancellation required" this would not > happen. Alternatively multiple REG_RESPONSEs could be allowed in one > packet. I do not see the two packets as problematic. > > I am not sure it is required to indicate different lifetimes for > > different services though. If you really want to handle various > > lifetime, you can get the same result by announcing the min > > lifetime of services you're offering for all services. > > This is confusing for the server administrator. If the server > supports two services S1 and S2 with lifetime boundaries configured > as: > > S1 min 30s max 120s > S2 min 3600s max 86400s > > the server would then signal [S1, S2 (30 86400)] in REG_INFO, and so > the administrator's configurations are not respected. > > Next, the client wants to register to service S2 for 3600 seconds and > sends a REG_REQUEST [S2 (3600)]. The server then checks the lifetime > boundaries for the service S2 again and sends a REG_RESPONSE [S2 > (120)]. > > Yep, this works, but it is illogical to signal different lifetime > boundaries than what are later granted. This issue could be easily > fixed by allowing multiple REG_INFOs / REG_RESPONSEs / REG_REQUESTs > in one packet or by altering the parameters' formats. It's not that illogical given that it's allowed by the spec: The requester MUST be prepared to receive any registration lifetime, including ones beyond the minimum and maximum lifetime indicated in the REG_INFO parameter. It MUST NOT expect that the returned lifetime will be the requested one, even when the requested lifetime falls within the announced minimum and maximum. > >> The REG_REQUEST case i.e. the client has requested redundant > >> services. The server should not allow any broken behavior from the > >> client. Therefore the whole packet having redundant services > >> should be just silently dropped. > > > > I disagree. If we follow the "be conservative in what you send, > > liberal in what you accept", a peer receiving duplicate > > registration types should just ignore the duplicated occurrences. > > Fair enough, but this should be said in the RFC. Well, I think it's reasonable to expect some common sense from an implementor -- And we could even debatable if duplicate service announcements really constitues an error... > >> > Again that would be broken behavior from the registrar side, we > >> > have a SHOULD there. If it doesn't do so, then it either doesn't > >> > reply or send REG_FAILED, in any case the MN would not be be > >> > mistaken in believing the cancellation was successful. > >> > >> Perhaps this could be clarified by saying "The Requester cannot > >> assume that the cancellation was successful until it receives a > >> REG_RESPONSE with a zero lifetime." > > > > I think this is implicit in the specification, don't you think so? > > Hmmm... > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC 2119 > [RFC2119]. > > RFC 2119: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that > there may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > So are "the full implications understood and carefully weighed" when > the server does not send a REG_RESPONSE? "Carefully weighing" for me > means that the issue is thought over and written in the RFC. I'm not > saying this is an important point, but if the RFC is to be revised, > the following clarification wouldn't hurt: > > "The Requester SHOULD NOT assume that the cancellation was successful > until it receives a REG_RESPONSE with a matching Reg Type and a zero > lifetime." Again, common sense IMHO covers that, but agree clarifying in a rev of the RFC would do no harm. > >> Yes, at least for the "Reg Types" with different "Min Lifetime" / > >> "Max Lifetime" / "Lifetime" values. > > > > As I said, not sure that's really needed for any usecase. And in > > case you really have a hard requirement to support that, you could > > configure different Registrars announcing different lifetimes w/ > > different HITs on the same node. That can be left to > > implementation. > > Good point, but this would increase the administrative work. > > -Lauri --julien _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec