Re: [Hipsec] HIP Registration Extension
Lauri Silvennoinen <ljsilven@cc.hut.fi> Tue, 19 August 2008 17:35 UTC
Return-Path: <hipsec-bounces@ietf.org>
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 <hipsec@core3.amsl.com>; 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 <hipsec@core3.amsl.com>; 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 <hipsec@ietf.org>; 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
From: Lauri Silvennoinen <ljsilven@cc.hut.fi>
To: Julien Laganier <julien.laganier.IETF@googlemail.com>
In-Reply-To: <48A9A97D.6010701@googlemail.com>
Message-ID: <Pine.OSF.4.64.0808191814110.362556@kosh.hut.fi>
References: <Pine.OSF.4.64.0808141955110.142735@kosh.hut.fi> <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." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
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
- [Hipsec] HIP Registration Extension (fwd) Lauri Silvennoinen
- Re: [Hipsec] HIP Registration Extension (fwd) Julien Laganier
- Re: [Hipsec] HIP Registration Extension Lauri Silvennoinen
- Re: [Hipsec] HIP Registration Extension Julien Laganier
- Re: [Hipsec] HIP Registration Extension Julien Laganier
- Re: [Hipsec] HIP Registration Extension Lauri Silvennoinen
- Re: [Hipsec] HIP Registration Extension Julien Laganier