From thomas.r.henderson@boeing.com Tue Nov 3 15:53:55 2009 Return-Path: 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 BA7F33A6897 for ; Tue, 3 Nov 2009 15:53:55 -0800 (PST) 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=[AWL=0.000, 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 2LD1zBSAbneq for ; Tue, 3 Nov 2009 15:53:55 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id E30C83A6841 for ; Tue, 3 Nov 2009 15:53:54 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA3NrvcV009699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Nov 2009 17:54:05 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA3Nrvdq001250; Tue, 3 Nov 2009 15:53:57 -0800 (PST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA3Nrvjw001247 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 3 Nov 2009 15:53:57 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 3 Nov 2009 15:53:56 -0800 From: "Henderson, Thomas R" To: "'miika.komu@hiit.fi'" , Petri Jokela Date: Tue, 3 Nov 2009 15:53:56 -0800 Thread-Topic: [Hipsec] Rechartering Thread-Index: Aco7j2Yk91wReNQoQCCjL1WQJTNWjghUUjlQ Message-ID: References: <4AB8C26C.5040209@ericsson.com> <4AB8DC69.2070105@hiit.fi> In-Reply-To: <4AB8DC69.2070105@hiit.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] Rechartering 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: , X-List-Received-Date: Tue, 03 Nov 2009 23:53:55 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Miika Komu > Sent: Tuesday, September 22, 2009 7:17 AM > To: Gonzalo Camarillo > Cc: HIP > Subject: Re: [Hipsec] Rechartering > > Gonzalo Camarillo wrote: > > Hi, > > > Folks, > > > > after discussing with our AD, we need to provide him with a > proposal for > > a new charter for the WG. The proposal needs to contain > details on the > > RFCs to be revised, the process we intend to follow to > revise them, and > > the timeline we are looking at. > > An issue tracker would be a useful tool to organizing the details. I > believe Petri was looking into one?) Hi Miika or Petri, Was an issue tracker ever set up for this work? If not, was someone planni= ng to volunteer to set it up? - Tom From miika.komu@hiit.fi Tue Nov 3 23:15:10 2009 Return-Path: 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 7F14D3A6860 for ; Tue, 3 Nov 2009 23:15:10 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEgKEaI1PBCH for ; Tue, 3 Nov 2009 23:15:09 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 490CD3A681D for ; Tue, 3 Nov 2009 23:15:08 -0800 (PST) Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id 42E3125ED26; Wed, 4 Nov 2009 09:15:29 +0200 (EET) Message-ID: <4AF12A1B.3000403@hiit.fi> Date: Wed, 04 Nov 2009 09:15:39 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4AB8C26C.5040209@ericsson.com> <4AB8DC69.2070105@hiit.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Rechartering X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 07:15:10 -0000 Henderson, Thomas R wrote: Hi, >> -----Original Message----- >> From: hipsec-bounces@ietf.org >> [mailto:hipsec-bounces@ietf.org] On Behalf Of Miika Komu >> Sent: Tuesday, September 22, 2009 7:17 AM >> To: Gonzalo Camarillo >> Cc: HIP >> Subject: Re: [Hipsec] Rechartering >> >> Gonzalo Camarillo wrote: >> >> Hi, >> >>> Folks, >>> >>> after discussing with our AD, we need to provide him with a >> proposal for >>> a new charter for the WG. The proposal needs to contain >> details on the >>> RFCs to be revised, the process we intend to follow to >> revise them, and >>> the timeline we are looking at. >> An issue tracker would be a useful tool to organizing the details. I >> believe Petri was looking into one?) > > Hi Miika or Petri, > Was an issue tracker ever set up for this work? If not, was someone planning to volunteer to set it up? I think Petri already set it up already: http://hip4inter.net/cgi-bin/roundup.cgi/ No issues are filed yet. The issues reported on the mailing list were summarized in the slide set. From petri.jokela@nomadiclab.com Tue Nov 3 23:36:04 2009 Return-Path: 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 5F22328C1DB for ; Tue, 3 Nov 2009 23:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 qGWjQY5QG3Pe for ; Tue, 3 Nov 2009 23:36:03 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 9589128C1DA for ; Tue, 3 Nov 2009 23:36:03 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 64BA21EF138; Wed, 4 Nov 2009 09:36:24 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJgLJcTA3ghR; Wed, 4 Nov 2009 09:36:23 +0200 (EET) Received: from [127.0.0.1] (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 53A8E1EF135; Wed, 4 Nov 2009 09:36:23 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Petri Jokela In-Reply-To: <4AF12A1B.3000403@hiit.fi> Date: Wed, 4 Nov 2009 09:36:27 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4AB8C26C.5040209@ericsson.com> <4AB8DC69.2070105@hiit.fi> <4AF12A1B.3000403@hiit.fi> To: miika.komu@hiit.fi X-Mailer: Apple Mail (2.1076) Cc: HIP Subject: Re: [Hipsec] Rechartering 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: , X-List-Received-Date: Wed, 04 Nov 2009 07:36:04 -0000 >>> >> Hi Miika or Petri, >> Was an issue tracker ever set up for this work? If not, was >> someone planning to volunteer to set it up? > > I think Petri already set it up already: > > http://hip4inter.net/cgi-bin/roundup.cgi/ > > No issues are filed yet. The issues reported on the mailing list > were summarized in the slide set. > The old ones do not work, there was some problems when the roundup was updated. RFC5201 is newly initiated and it seems to work. I will setup new ones, and maybe try to recover the old ones to refresh our memories, but it takes few days due to other activities. /Petri From mglt.ietf@gmail.com Sun Nov 8 18:23:56 2009 Return-Path: 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 EB52A28C0FC for ; Sun, 8 Nov 2009 18:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=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 d0nSDK0BaPnz for ; Sun, 8 Nov 2009 18:23:56 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 917C628C0E0 for ; Sun, 8 Nov 2009 18:23:55 -0800 (PST) Received: by bwz23 with SMTP id 23so2968857bwz.29 for ; Sun, 08 Nov 2009 18:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=u5A3Fc81y8WIc0c7h7D7g9RFZPHEI+W7WPcr+cdmo68=; b=bebLfODJMAIc64bLGWR5I8JSr+Ep/UnGoY+W/+nmsmfAnc5+9DENq9B38tR5KRu8gi 0qpkk4sZZVN3aR876ksXbDTzUqKVHE85s85pYaSZGZAynqhMVA3g5yX/llSp0Lo7JbCv cgDMTw/WO4k2lS/Rpk4ZiVfAr7SSa4KxM28PI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=GCz8SlefhIKUsWOwJ9TBj4+DPX8EcDCO9+8XrOTFz3WJg5KLqLYcq5l6wkGm35xrHX zGNFuDGemjjhl3Bak49743qQlmu0JcC2DUN1jsQHgvb9tAMTh9YZd3oVEe25l+fvkW0K ONCPztNeiUDIEngnJK03pZwMwSr9qTsNC6pFg= MIME-Version: 1.0 Received: by 10.102.248.11 with SMTP id v11mr2783014muh.91.1257733456370; Sun, 08 Nov 2009 18:24:16 -0800 (PST) Date: Mon, 9 Nov 2009 03:24:16 +0100 Message-ID: <51eafbcb0911081824ve8547deu8be8ea3d9e575642@mail.gmail.com> From: Daniel Migault To: Pascal Urien Content-Type: multipart/alternative; boundary=0016364166d1e39b760477e6e3c7 Cc: hipsec@ietf.org Subject: [Hipsec] iot for hip 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: , X-List-Received-Date: Mon, 09 Nov 2009 02:23:57 -0000 --0016364166d1e39b760477e6e3c7 Content-Type: text/plain; charset=ISO-8859-1 Hi Pascal, I briefly went through the document. IoT was probably missing this kind of document with a problem statement, so that we can understand why HIP is the more accurate solution to deal with IoT. Although I am not an expert on IoT, I am not convinced HIP is the only single protocol to consider. With Security related issues maybe IPsec suite protocols as well as ID - IP address binding protocols (like CGA) could also solve some of the issues. IoT to some extends looks to have similarities with what is 6lowpan. Maybe we should explicitly mention why IoT cannot be included in 6lowpan. Regards, Daniel On Fri, Oct 16, 2009 at 10:04 AM, Pascal Urien wrote: > Hi Every Body, > > During the last WG meeting in Stockholm we discuss about a possible WG item > addressing HIP for internet of things > > I would like a slot during the next meeting at Hiroshima, in order to > preset the draft draft-urien-hip-iot that tries to start a woork with HIP > and IOT > > > Best Regards > > Pascal > > > Filename: draft-urien-hip-iot > Version: 00 > Staging URL: http://www.ietf.org/staging/draft-urien-hip-iot-00.txt > Title: HIP for IoT > Creation_date: 2009-10-16 > WG ID: Indvidual Submission > Number_of_pages: 6 > Abstract: > The goal of this document is to analyze issues raised by the > deployment of the Internet Of Things, and to propose a framework > based on an Identity Layer such as the HIP protocol. > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016364166d1e39b760477e6e3c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pascal,

I briefly went through the document. IoT was probably mi= ssing this kind of document with a problem statement, so that we can unders= tand why HIP is the more accurate solution to deal with IoT.

Althoug= h I am not an expert on IoT, I am not convinced HIP is the only single=A0 p= rotocol to consider. With Security related issues maybe=A0 IPsec suite prot= ocols as well as ID - IP address binding protocols (like CGA) could also so= lve some of the issues.

IoT to some extends looks to have similarities with what is 6lowpan. Ma= ybe we should explicitly mention why IoT cannot be included in 6lowpan.
=
Regards,

Daniel=A0


On Fr= i, Oct 16, 2009 at 10:04 AM, Pascal Urien <pascal.urien@gmail.com> wrote:=
Hi Every Bod= y,
=A0
During the last WG meeting in Stockholm we discuss about a possible WG= item addressing HIP for internet of things
=A0
I would like a slot during the next meeting at Hiroshima, in order to = preset the draft draft-urien-hip-iot that tries to start a woork with HIP a= nd IOT
=A0
=A0
Best Regards
=A0
Pascal
=A0
=A0
Filename: =A0 =A0 =A0 =A0 =A0draft-urien-hip-iot
Version: =A0 =A0 = =A0 =A0 =A0 00
Staging URL: =A0 =A0 =A0 http://www.ietf.org/st= aging/draft-urien-hip-iot-00.txt
Title: =A0 =A0 =A0 =A0 =A0 =A0 HIP for IoT
Creation_date: =A0 =A0 2009-1= 0-16
WG ID: =A0 =A0 =A0 =A0 =A0 =A0 Indvidual Submission
Number_of_pa= ges: 6
Abstract:
The goal of this document is to analyze issues raise= d by the
deployment of the Internet Of Things, and to propose a framewor= k
based on an Identity Layer such as the HIP protocol.

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




--
Daniel Migault
O= range Labs -- Security
+33 6 70 72 69 58
--0016364166d1e39b760477e6e3c7-- From wwwrun@core3.amsl.com Fri Nov 6 01:22:04 2009 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 584DF28C168; Fri, 6 Nov 2009 01:22:04 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091106092204.584DF28C168@core3.amsl.com> Date: Fri, 6 Nov 2009 01:22:04 -0800 (PST) X-Mailman-Approved-At: Mon, 09 Nov 2009 22:43:34 -0800 Cc: hip mailing list , Internet Architecture Board , hip chair , RFC Editor Subject: [Hipsec] Document Action: 'Basic HIP Extensions for Traversal of Network Address Translators' to Experimental RFC 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: , X-List-Received-Date: Fri, 06 Nov 2009 09:22:04 -0000 The IESG has approved the following document: - 'Basic HIP Extensions for Traversal of Network Address Translators ' as an Experimental RFC This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-09.txt Technical Summary This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications. Working Group Summary There was nothing in the Working Group review process worth noting. Document Quality There are at least two independent implementations of this document. These implementations have been tested against each other and are interoperable. The WG did not want to request the publication of this document before having independent interoperable implementations. That is why we did not requested the publication of this draft before. Personnel Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd. Ralph Droms (rdroms@cisco.com) is the responsible AD. From jan.melen@nomadiclab.com Wed Nov 11 20:34:10 2009 Return-Path: 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 837DE3A67A6 for ; Wed, 11 Nov 2009 20:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_SE=0.35, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 RWt9kCVkfRhj for ; Wed, 11 Nov 2009 20:34:09 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 42D2C3A677E for ; Wed, 11 Nov 2009 20:34:09 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 43CA41EF1EA for ; Thu, 12 Nov 2009 06:34:37 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5LdEowNB4a1 for ; Thu, 12 Nov 2009 06:34:36 +0200 (EET) Received: from esealmw967.eemea.ericsson.se (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 03B481EF12E for ; Thu, 12 Nov 2009 06:34:34 +0200 (EET) From: Jan Melen Content-Type: multipart/alternative; boundary=Apple-Mail-146-520398897 Date: Thu, 12 Nov 2009 06:34:32 +0200 References: <20091019214502.334AA3A6981@core3.amsl.com> To: hipsec@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [Hipsec] Fwd: I-D Action:draft-carpenter-behave-referral-object-01.txt 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: , X-List-Received-Date: Thu, 12 Nov 2009 04:34:10 -0000 --Apple-Mail-146-520398897 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, Here is draft which could be considered when defining the bis draft 5201. I think we should see where this goes and consider if we need to adapt our HI format to GRO format for compatibility. Regards, Jan Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 20, 2009 12:45:02 AM GMT+03:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-carpenter-behave-referral-object-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A Generic Referral Object for Internet Entities > Author(s) : B. Carpenter, et al. > Filename : draft-carpenter-behave-referral-object-01.txt > Pages : 23 > Date : 2009-10-19 > > The purpose of a referral is to enable a given entity in a multiparty > application to pass information to another party. This memo > specifies a Generic Referral Object (GRO) to be used in the context > of referrals. The proposed object is compact and is application- > independent. Both IPv4 and IPv6 schemes are supported, as well as > upper layer identifiers. Additional information to characterise an > enclosed reference is also described. To allow proper interpretation > of referrals, a new notion of scope identifiers is introduced. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-behave-referral-object-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-146-520398897 Content-Type: multipart/mixed; boundary=Apple-Mail-147-520398898 --Apple-Mail-147-520398898 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: October 20, 2009 12:45:02 AM = GMT+03:00
Subject: I-D = Action:draft-carpenter-behave-referral-object-01.txt =
Reply-To: internet-drafts@ietf.org
<= /span>

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

Title =           : A Generic = Referral Object for Internet Entities
Author(s) =       : B. Carpenter, et al.
Filename =        : = draft-carpenter-behave-referral-object-01.txt
Pages =           : = 23
= Date =            : = 2009-10-19

The purpose of a referral is to enable a given entity = in a multiparty
application to pass information to another party. =  This memo
specifies a Generic Referral Object (GRO) to be used = in the context
of referrals.  The proposed object is compact and = is application-
independent.  Both IPv4 and IPv6 schemes are = supported, as well as
upper layer identifiers.  Additional = information to characterise an
enclosed reference is also described. =  To allow proper interpretation
of referrals, a new notion of = scope identifiers is introduced.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-carpenter-behav= e-referral-object-01.txt

Internet-Drafts are also available = by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below = is the data which will enable a MIME compliant mail = reader
implementation to automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-147-520398898 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-10-19143421.I-D@ietf.org>

--Apple-Mail-147-520398898 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-147-520398898-- --Apple-Mail-146-520398897-- From rgm@htt-consult.com Wed Nov 18 13:04:07 2009 Return-Path: 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 6D20A3A6A88 for ; Wed, 18 Nov 2009 13:04:07 -0800 (PST) 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=[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 T0A6RYbh12Pr for ; Wed, 18 Nov 2009 13:04:06 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 890D53A6864 for ; Wed, 18 Nov 2009 13:04:06 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id EA26C68235 for ; Wed, 18 Nov 2009 21:02:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5s1ux3HEWiq for ; Wed, 18 Nov 2009 16:02:25 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.154.28.181]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id B14CE68149 for ; Wed, 18 Nov 2009 16:02:25 -0500 (EST) Message-ID: <4B04610D.6050208@htt-consult.com> Date: Wed, 18 Nov 2009 16:03:09 -0500 From: Robert Moskowitz User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] SPIs and IPv6 address indexing 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: , X-List-Received-Date: Wed, 18 Nov 2009 21:04:07 -0000 Consider a VERY constrained PHY/MAC. Where signal fade makes it hard to get large datagrams through and you want to do everything you can to shorten the datagrams. These exist. I just sat through two presentations in IEEE 802.15.4g with real measurements and separate modeling validation (actually two different groups only becoming aware of the other when they published their data) on significant channel fade problems.... So here we are with ESP and its SPI. Per RFC 5202, the SPI is a mapping of the Destination HIP SA. This tells the receiver what are both the HIT and IPv6 pairs it is to use in processing the ESP datagram. So for traffic strickly on the constrained local link, it would seem that the IPv6 addresses are not 'needed' on the link, as there is a mapping of SPI to IPv6 addresses that map to MAC addresses. And there are always the MAC addresses in the datagram anyway. This ASSuMEs that two different Initiators did not use the same SPI with a given Responder (or two Responders to Initiator). Given that SPIs are ONLY 32 bits, collisions probably really happen? But again you do have the MAC addresses to help keep this all straight. So maybe this is not such a concern. Now what about traffic that goes through a Midbox off the constrained local net. The Midbox could have the SPI to Addr mapping from the HIP exchange, but then the Midbox has to be aware of all mobility Updates? Perhaps a bit complex. But there is a real incentive here to shave off considerable overhead that can be the make-it/break-it point for the link.... I am sure that there is some good discussions of this somewhere.... Why did I ever get involved again with MACs? It is sooooo much easier to just pretend they are all the same. From miika.komu@hiit.fi Wed Nov 18 14:11:42 2009 Return-Path: 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 D35BB3A690E for ; Wed, 18 Nov 2009 14:11:42 -0800 (PST) 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=[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 cMSrkeEzXcnH for ; Wed, 18 Nov 2009 14:11:40 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id C3B7128C0D0 for ; Wed, 18 Nov 2009 14:11:33 -0800 (PST) Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id D1DD825ED13; Thu, 19 Nov 2009 00:11:29 +0200 (EET) Message-ID: <4B047112.9040902@hiit.fi> Date: Thu, 19 Nov 2009 00:11:30 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Robert Moskowitz References: <4B04610D.6050208@htt-consult.com> In-Reply-To: <4B04610D.6050208@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] SPIs and IPv6 address indexing X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 22:11:43 -0000 Robert Moskowitz wrote: Hi, > Consider a VERY constrained PHY/MAC. Where signal fade makes it hard to > get large datagrams through and you want to do everything you can to > shorten the datagrams. These exist. I just sat through two > presentations in IEEE 802.15.4g with real measurements and separate > modeling validation (actually two different groups only becoming aware > of the other when they published their data) on significant channel fade > problems.... > > So here we are with ESP and its SPI. Per RFC 5202, the SPI is a mapping > of the Destination HIP SA. This tells the receiver what are both the > HIT and IPv6 pairs it is to use in processing the ESP datagram. > > So for traffic strickly on the constrained local link, it would seem > that the IPv6 addresses are not 'needed' on the link, as there is a > mapping of SPI to IPv6 addresses that map to MAC addresses. And there > are always the MAC addresses in the datagram anyway. > > This ASSuMEs that two different Initiators did not use the same SPI with > a given Responder (or two Responders to Initiator). Given that SPIs are > ONLY 32 bits, collisions probably really happen? But again you do have > the MAC addresses to help keep this all straight. So maybe this is not > such a concern. > > Now what about traffic that goes through a Midbox off the constrained > local net. The Midbox could have the SPI to Addr mapping from the HIP > exchange, but then the Midbox has to be aware of all mobility Updates? > Perhaps a bit complex. But there is a real incentive here to shave off > considerable overhead that can be the make-it/break-it point for the > link.... > > I am sure that there is some good discussions of this somewhere.... > > Why did I ever get involved again with MACs? It is sooooo much easier > to just pretend they are all the same. I have to remind about the SPINAT work from Ylitalo et al. I think the UDP is a more practical way to support HIP and ESP to make better guarantees about middlebox traversal in general. Further, the UDP port numbers can be used to replace the MAC address bindings in your approach? From rgm@htt-consult.com Wed Nov 18 14:33:58 2009 Return-Path: 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 4E5563A6AE9 for ; Wed, 18 Nov 2009 14:33:58 -0800 (PST) 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=[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 XslAPQ5tpYku for ; Wed, 18 Nov 2009 14:33:57 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 617793A6AE5 for ; Wed, 18 Nov 2009 14:33:57 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 0E32168B22; Wed, 18 Nov 2009 22:32:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo-tMW0nNpzN; Wed, 18 Nov 2009 17:32:16 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.154.28.10]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id F148C68149; Wed, 18 Nov 2009 17:32:15 -0500 (EST) Message-ID: <4B04761F.3000406@htt-consult.com> Date: Wed, 18 Nov 2009 17:33:03 -0500 From: Robert Moskowitz User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: miika.komu@hiit.fi References: <4B04610D.6050208@htt-consult.com> <4B047112.9040902@hiit.fi> In-Reply-To: <4B047112.9040902@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] SPIs and IPv6 address indexing 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: , X-List-Received-Date: Wed, 18 Nov 2009 22:33:58 -0000 Miika Komu wrote: > Robert Moskowitz wrote: > > Hi, > >> Consider a VERY constrained PHY/MAC. Where signal fade makes it hard >> to get large datagrams through and you want to do everything you can >> to shorten the datagrams. These exist. I just sat through two >> presentations in IEEE 802.15.4g with real measurements and separate >> modeling validation (actually two different groups only becoming >> aware of the other when they published their data) on significant >> channel fade problems.... >> >> So here we are with ESP and its SPI. Per RFC 5202, the SPI is a >> mapping of the Destination HIP SA. This tells the receiver what are >> both the HIT and IPv6 pairs it is to use in processing the ESP datagram. >> >> So for traffic strickly on the constrained local link, it would seem >> that the IPv6 addresses are not 'needed' on the link, as there is a >> mapping of SPI to IPv6 addresses that map to MAC addresses. And >> there are always the MAC addresses in the datagram anyway. >> >> This ASSuMEs that two different Initiators did not use the same SPI >> with a given Responder (or two Responders to Initiator). Given that >> SPIs are ONLY 32 bits, collisions probably really happen? But again >> you do have the MAC addresses to help keep this all straight. So >> maybe this is not such a concern. >> >> Now what about traffic that goes through a Midbox off the constrained >> local net. The Midbox could have the SPI to Addr mapping from the >> HIP exchange, but then the Midbox has to be aware of all mobility >> Updates? Perhaps a bit complex. But there is a real incentive here >> to shave off considerable overhead that can be the make-it/break-it >> point for the link.... >> >> I am sure that there is some good discussions of this somewhere.... >> >> Why did I ever get involved again with MACs? It is sooooo much >> easier to just pretend they are all the same. > > I have to remind about the SPINAT work from Ylitalo et al. I think the > UDP is a more practical way to support HIP and ESP to make better > guarantees about middlebox traversal in general. Further, the UDP port > numbers can be used to replace the MAC address bindings in your approach? Well this is strictly an IPv6 world, so middle boxes are not NATing unless you buy into NAT66. There is no reason for even NAT66 in my view of this world, all the devices have IPv6 addresses with the prefixes handed out through some mechanism. The issue is packet compression, so running ESP over UDP becomes an upstream battle :) From rgm@htt-consult.com Thu Nov 19 07:35:26 2009 Return-Path: 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 C56673A695C for ; Thu, 19 Nov 2009 07:35:26 -0800 (PST) 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=[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 lWZBcBsflYXF for ; Thu, 19 Nov 2009 07:35:25 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 989EF3A6960 for ; Thu, 19 Nov 2009 07:35:25 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 9BBD268B20; Thu, 19 Nov 2009 15:33:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnnH4KXOpvEn; Thu, 19 Nov 2009 10:33:40 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.154.28.181]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1E8A268149; Thu, 19 Nov 2009 10:33:40 -0500 (EST) Message-ID: <4B056582.3040203@htt-consult.com> Date: Thu, 19 Nov 2009 10:34:26 -0500 From: Robert Moskowitz User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: gabriel montenegro References: <4B04610D.6050208@htt-consult.com> <4B047112.9040902@hiit.fi> <4B04761F.3000406@htt-consult.com> <170710.98812.qm@web82608.mail.mud.yahoo.com> In-Reply-To: <170710.98812.qm@web82608.mail.mud.yahoo.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] SPIs and IPv6 address indexing 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: , X-List-Received-Date: Thu, 19 Nov 2009 15:35:26 -0000 gabriel montenegro wrote: > You might want to look at what we did in 6lowpan for header compression of IPv6 over 802.15.4: > > http://tools.ietf.org/html/rfc4944#section-10 > I have. > For example, in some situations one may completely elide the IPv6 addresses if they are derived in a known way from the MAC EUI-64 addresses. > Yes. > Further header compression work is going on in: > http://tools.ietf.org/wg/6lowpan/draft-ietf-6lowpan-hc/ > I am following this. > Gabriel > > > ----- Original Message ---- > >> From: Robert Moskowitz >> To: miika.komu@hiit.fi >> Cc: hipsec@ietf.org >> Sent: Wed, November 18, 2009 5:33:03 PM >> Subject: Re: [Hipsec] SPIs and IPv6 address indexing >> >> Miika Komu wrote: >> >>> Robert Moskowitz wrote: >>> >>> Hi, >>> >>> >>>> Consider a VERY constrained PHY/MAC. Where signal fade makes it hard to get >>>> >> large datagrams through and you want to do everything you can to shorten the >> datagrams. These exist. I just sat through two presentations in IEEE 802.15.4g >> with real measurements and separate modeling validation (actually two different >> groups only becoming aware of the other when they published their data) on >> significant channel fade problems.... >> >>>> So here we are with ESP and its SPI. Per RFC 5202, the SPI is a mapping of >>>> >> the Destination HIP SA. This tells the receiver what are both the HIT and IPv6 >> pairs it is to use in processing the ESP datagram. >> >>>> So for traffic strickly on the constrained local link, it would seem that the >>>> >> IPv6 addresses are not 'needed' on the link, as there is a mapping of SPI to >> IPv6 addresses that map to MAC addresses. And there are always the MAC >> addresses in the datagram anyway. >> >>>> This ASSuMEs that two different Initiators did not use the same SPI with a >>>> >> given Responder (or two Responders to Initiator). Given that SPIs are ONLY 32 >> bits, collisions probably really happen? But again you do have the MAC >> addresses to help keep this all straight. So maybe this is not such a concern. >> >>>> Now what about traffic that goes through a Midbox off the constrained local >>>> >> net. The Midbox could have the SPI to Addr mapping from the HIP exchange, but >> then the Midbox has to be aware of all mobility Updates? Perhaps a bit >> complex. But there is a real incentive here to shave off considerable overhead >> that can be the make-it/break-it point for the link.... >> >>>> I am sure that there is some good discussions of this somewhere.... >>>> >>>> Why did I ever get involved again with MACs? It is sooooo much easier to >>>> >> just pretend they are all the same. >> >>> I have to remind about the SPINAT work from Ylitalo et al. I think the UDP is >>> >> a more practical way to support HIP and ESP to make better guarantees about >> middlebox traversal in general. Further, the UDP port numbers can be used to >> replace the MAC address bindings in your approach? >> >> Well this is strictly an IPv6 world, so middle boxes are not NATing unless you >> buy into NAT66. There is no reason for even NAT66 in my view of this world, all >> the devices have IPv6 addresses with the prefixes handed out through some >> mechanism. The issue is packet compression, so running ESP over UDP becomes an >> upstream battle :) >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > > >