Re: [Hipsec] RFC5204-bis open issues?

Julien Laganier <julien.ietf@gmail.com> Fri, 09 January 2015 03:19 UTC

Return-Path: <julien.ietf@gmail.com>
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 A9A141A86DF for <hipsec@ietfa.amsl.com>; Thu, 8 Jan 2015 19:19:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 K5JQj-Gy4z-W for <hipsec@ietfa.amsl.com>; Thu, 8 Jan 2015 19:19:23 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0153E1A854D for <hipsec@ietf.org>; Thu, 8 Jan 2015 19:19:22 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id pv20so12486144lab.13 for <hipsec@ietf.org>; Thu, 08 Jan 2015 19:19:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pLg5aav7ONNK4f5pHmgWXpIu7xLpPik8150AZXk2enA=; b=dgM/DgiA0K7yk5a7/O7XXIXgds46b+qVoPOJRuuH6ZAlaJJAzUOQC8XCRPuwB4dLaK Bx3rhrspDHXp391UsKA223vJMJbxiN7mG6F8sbrPjXFfHJTpT+pKarDV75cprgwlgkPo pNZcnMxaayZn16YJm2sYkUdPEIa4bODJEv/JYZdY/ohmEuBp/at0AHFwQT+rjEXScasb jYn/nMu2o9Pxs//QV4JW2Nrhu/CSTBUMCDUs0MA0lnJfjyhC/bluCcCKPCdVff9MmDZ2 demnl60KXjdeEivAt9CTomsjnjIgu7DZpEZX3dKrvQEJfoolQhAJZfayuKydMdmNZcNq +kYw==
MIME-Version: 1.0
X-Received: by 10.152.234.35 with SMTP id ub3mr19176852lac.70.1420773561106; Thu, 08 Jan 2015 19:19:21 -0800 (PST)
Received: by 10.25.151.7 with HTTP; Thu, 8 Jan 2015 19:19:21 -0800 (PST)
In-Reply-To: <549EFF21.2030707@cs.hut.fi>
References: <54905061.1010200@tomh.org> <549EFF21.2030707@cs.hut.fi>
Date: Thu, 08 Jan 2015 19:19:21 -0800
Message-ID: <CAE_dhjvL9dizn7tJ9psEreu9TJVAOtqpSU7K1xruVoTjXiOxHw@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: Miika Komu <mkomu@cs.hut.fi>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/fvZ2Mz6_G2lC2NzdRw6ioT4a3oU>
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] RFC5204-bis open issues?
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." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jan 2015 03:19:25 -0000

On Sat, Dec 27, 2014 at 10:49 AM, Miika Komu <mkomu@cs.hut.fi> wrote:
> Hi Tom,
>
> On 12/16/2014 05:31 PM, Tom Henderson wrote:
>>
>> I noticed that the draft for RFC5204-bis (rendezvous extension) was
>> recently refreshed, and was wondering what the remaining open issues are
>> for this draft?
>>
>> I know of only one, which is a longstanding question of whether we want
>> to cover RVS relaying of UPDATE messages in this specification.
>>
>> https://tools.ietf.org/wg/hip/trac/ticket/1
>>
>> Some choices appear to be:
>>
>> * do not support double jump in these specifications, leaving it for
>> further study
>> * add specification in RFC5204-bis that refers to UPDATE relaying
>> * add specification in RFC5206-bis that refers to UPDATE relaying
>
>
> I suggest the third option (unless Julien wants to write it in RFC5204).
> Besides UPDATE relaying, we need also some text for the other side, i.e.,
> the registered host moves and updates its registration.

I also think the third option is the best. The relaying of UPDATEs
messages is not required for a non-mobile host so RFC5204bis doesn't
sound right since it documents a generic rendezvous mechanism that can
be applied to a non-mobile host. On the other hand RFC5206bis is
specifically concerned with host mobility so that seem to be a good
place to add the extra bits of specification.

--julien