IETF Logo Mail Archive

Re: [Hipsec] rfc5206-bis issue review

Tobias Heer <heer@cs.rwth-aachen.de> Mon, 19 September 2011 15:20 UTC

Return-Path: <heer@informatik.rwth-aachen.de>
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 BBC4E21F8C63 for <hipsec@ietfa.amsl.com>; Mon, 19 Sep 2011 08:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.615
X-Spam-Level:
X-Spam-Status: No, score=-4.615 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
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 RaL7e4Pllvuf for <hipsec@ietfa.amsl.com>; Mon, 19 Sep 2011 08:20:51 -0700 (PDT)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id A67AD21F8C5E for <hipsec@ietf.org>; Mon, 19 Sep 2011 08:20:51 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LRS00CE202O9L60@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 19 Sep 2011 17:23:12 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.68,405,1312149600"; d="scan'208";a="64201797"
Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Mon, 19 Sep 2011 17:23:12 +0200
Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LRS008SR02OUQ10@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 19 Sep 2011 17:23:12 +0200 (CEST)
From: Tobias Heer <heer@cs.rwth-aachen.de>
In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CEFAF070F@XCH-NW-10V.nw.nos.boeing.com>
Date: Mon, 19 Sep 2011 17:23:13 +0200
Content-transfer-encoding: quoted-printable
Message-id: <155E3DDD-DFF7-464C-A57B-8DD4B28B05D4@cs.rwth-aachen.de>
References: <7CC566635CFE364D87DC5803D4712A6C4CEFAF070F@XCH-NW-10V.nw.nos.boeing.com>
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
X-Mailer: Apple Mail (2.1084)
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] rfc5206-bis issue review
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: Mon, 19 Sep 2011 15:20:53 -0000

Hi Tom,

sorry for the late reply. Better late then never, huh? I agree in all points.

Am 08.09.2011 um 17:48 schrieb Henderson, Thomas R:

> I would like to post a revision of draft-ietf-hip-rfc5206-bis (mobility) and to close these issues (tracked here:  http://trac.tools.ietf.org/wg/hip/trac/query?component=rfc5206-bis)

...

> Ticket 14:  can actual IP addresses of UPDATEs be used as locators, even if not in LOCATOR set?
> ----------------------------------------------
> Propose to add a statement at the end of the section 5.3 Handling Received LOCATOR_SETs:
> 
> "A host MAY add the source IP address of a received HIP packet as a candidate locator for the peer even if it is not listed in the peer's LOCATOR_SET, but it SHOULD prefer locators explicitly listed in the LOCATOR_SET."

This is important. Good solution.
> 
> 
> 
....

> Ticket 15:  suggestion for naming UPDATE packets
> ------------------------------------------------
> The request here is to reduce the number of possible different UPDATE scenarios, document them better, and modularize the separate concepts.  This should probably be discussed in a separate thread.

This will probably be quite some work but I think its worth the effort. René has been thinking about this.

BR, 

Tobias


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

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://www.comsys.rwth-aachen.de/team/tobias-heer/
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi
pgp id: AEECA5BF

v2.20.3 | Report a Bug | By Email