Re: [Hipsec] Status of WG items

Ari Keranen <ari.keranen@nomadiclab.com> Fri, 27 July 2012 16:23 UTC

Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6C321F87C4 for <hipsec@ietfa.amsl.com>; Fri, 27 Jul 2012 09:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA1mjPzR2bwL for <hipsec@ietfa.amsl.com>; Fri, 27 Jul 2012 09:23:31 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id E2E6021F85F0 for <hipsec@ietf.org>; Fri, 27 Jul 2012 09:23:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 0F2904E6E9; Fri, 27 Jul 2012 19:23:22 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aonm3dRB8mJf; Fri, 27 Jul 2012 19:23:21 +0300 (EEST)
Received: from tri59.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 3790A4E679; Fri, 27 Jul 2012 19:23:21 +0300 (EEST)
Message-ID: <5012C05B.6080203@nomadiclab.com>
Date: Fri, 27 Jul 2012 19:22:51 +0300
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Julien Laganier <julien.ietf@gmail.com>
References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <CAE_dhjveQ6WVVE3BVKk2txfBxNhfWvjbz+QVU2P919dNZ1WO4A@mail.gmail.com>
In-Reply-To: <CAE_dhjveQ6WVVE3BVKk2txfBxNhfWvjbz+QVU2P919dNZ1WO4A@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: hipsec@ietf.org, Julien Laganier <julien.laganier@gmail.com>
Subject: Re: [Hipsec] Status of WG items
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Jul 2012 16:23:32 -0000

Hi Julien,

On 7/6/12 3:37 AM, Julien Laganier wrote:
> - 5203bis (registration) can IMHO be republished as is as I haven't
> seen any issue with the original version. If people agree I could
> republish it and we could WGLC it...

I posted some comments about 5203bis earlier this year but back then 
there was no discussion regarding them. So, here goes again.

Some of these have been discussed also earlier on this list (these 
relate to requirements discovered with the native NAT traversal draft 
[1]), but I'll have them all here for easier reference.

Currently, the registrar has no way of indicating that it would 
otherwise accept the registration, but it's currently running low on 
resources. For this purpose, a failure type "Insufficient resources" 
could be added to the "registration failure types".

Registration using authentication with certificates could be part of the 
registration RFC. Currently, only authentication with HI is defined, but 
knowing all HIs beforehand is not practical in many cases.

Text in section 3.2. of [1] could be used as a basis for this (just 
replace "HIP' data relay" with "registrar"). Also, if this 
authentication mode is added to the draft, failure type "Invalid 
certificate" should be added for the failure case.

Should we have these in the registration draft?


Cheers,
Ari

[1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal