From rgm@htt-consult.com Thu Jul 1 09:09:06 2010 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 E0A9A28C0D7 for ; Thu, 1 Jul 2010 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.976, 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 IiHy-dsabMLf for ; Thu, 1 Jul 2010 09:09:04 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 87E6C3A6807 for ; Thu, 1 Jul 2010 09:09:04 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 3935968B56 for ; Thu, 1 Jul 2010 16:01:10 +0000 (UTC) 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 rQFam39+c+1x for ; Thu, 1 Jul 2010 12:01:01 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 152FD68B4B for ; Thu, 1 Jul 2010 12:01:01 -0400 (EDT) Message-ID: <4C2CBDA0.7010603@htt-consult.com> Date: Thu, 01 Jul 2010 12:09:04 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-rfc5201-bis-02 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, 01 Jul 2010 16:09:06 -0000 For your reading pleasure! -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Thursday, July 01, 2010 11:59 AM To: robert.moskowitz@icsalabs.com Cc: petri.jokela@nomadiclab.com; thomas.r.henderson@boeing.com; heer@cs.rwth-aachen.de Subject: New Version Notification for draft-moskowitz-hip-rfc5201-bis-02 A new version of I-D, draft-moskowitz-hip-rfc5201-bis-02.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Filename: draft-moskowitz-hip-rfc5201-bis Revision: 02 Title: Host Identity Protocol Creation_date: 2010-07-01 WG ID: Independent Submission Number_of_pages: 112 Abstract: This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. The IETF Secretariat. From rgm@htt-consult.com Thu Jul 1 09:12:35 2010 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 2C88D3A684D for ; Thu, 1 Jul 2010 09:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_40=-0.185] 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 9Q8sSy4RsAqr for ; Thu, 1 Jul 2010 09:12:31 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id A6C8D3A659A for ; Thu, 1 Jul 2010 09:12:30 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 494B868B4B for ; Thu, 1 Jul 2010 16:04:35 +0000 (UTC) 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 1tR9FJnPB7DA for ; Thu, 1 Jul 2010 12:04:25 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id A760568B56 for ; Thu, 1 Jul 2010 12:04:25 -0400 (EDT) Message-ID: <4C2CBE6D.8080800@htt-consult.com> Date: Thu, 01 Jul 2010 12:12:29 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Welcome to 5201-bis-02 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, 01 Jul 2010 16:12:35 -0000 Tobias Heer with my able assistance, has completed the lastest effort to move 5201 (and HIP!) to cryto agility and standards track. Well I will say that Tobias did most of the writing, but I'll take the heat on where we went with the changes. Tobias figured out how to add the crypto agility and avoid some downgrade attacks. I spent time figuring out how to add ECDSA to the document and changes to KEYMAT. There ARE a number of changes, we changed the version number. HIP BEX still functions as in 5201, but we had to make the Hash negotiable, add ECDSA, and more Diffie-Hellman options (like ECDH). This resulted in some interesting changes. Tobias, Miika, and I have spent considerable time debating what crypto suites to include. We are trying to balance agility and compactness. Should we drop SHA-1 like a hot potato and just specify SHA-256 and -384 until SHA-3 comes out? Or should SHA-1 still play and we downplay SHA_384? Or is SHA-384 locked in to meet Suite-B needs? Which ECDSA key sizes, P160, P256, and P384 seem to be the minimum (read why for P160). And finally which AES modes (duo modes excluded for HIP payloads). So please think on this and weigh in with your views. First notice the change to the HIT. We realized we need to encode a HIT_Suite_ID into the HIT. Without this there were a number of complications and attack options. But this cost us 4 bits from the hash. We have a limited number of Suite ID slots and are concerned about how many we eat up right out the door. Note that each hash eats TWO IDs, one for RSA/DSA and one for ECDSA (also HIP DEX will take one more). The only change to the previous state machine is a transition from state I1-SENT to I1-SENT - the restart option. An Initiator is required to restart the HIP exchange if the Responder does not support the HIT Suite of the Initiator. Note that I have made additional changes to the state machine in HIP DEX to add aggresive retransmission. Take a read of that and we can discuss if BEX would benefit from this feature. Next on the the puzzle. Basically we made the size of I and J variable to the size of the keying needed. Plus the hash is the one in the HIT_Suite_ID. We have added a Diffie-Hellman list into I1. Read the text on what is going on here. More choices, hints needed, downgrade attacks to avoid. HOST_ID parameter got reworked. There is no ECDSA RDATA currently and the ID is limited to just NIST-ECDSA-256 and NIST-ECDSA-384. We needed at least BrainpoolP160r1, and perhaps more. So I changed even the handling of RSA and DSA to be ONLY the specifics from their DNSSEC RFCs. Then I built up how ECDSA should be handled, using draft-mcgrew-fundamental-ecc-03.txt. The HMAC parameters are renamed MAC, but in 5201 they are still using HMAC with the hash specified in the HIT-Suite_ID. HIP_Transform has been replaced by HIP_Cipher. The hash is locked down by the HIT_Suite_ID, so the only thing to negotiate is what cipher will be used for things like the ENCRYPTED parameter. I redid KEYMAT to directly use RFC 5869. The changes were slight, but it puts us using a new standard for hash-based KEYMAT. IANA considerations has been increased. We need some help with the Appendices;.B and C in particular. Anyway, please start reading. We will collect comments. Those which are obvious we will incorporate in a -03 to publish just before the July 12th cutoff date. Others we will organize into discussion points for the 5201-bis reading gathering. From rgm@htt-consult.com Thu Jul 1 09:31:12 2010 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 BF2063A6875 for ; Thu, 1 Jul 2010 09:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.927, 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 NzrXnSDHQQHi for ; Thu, 1 Jul 2010 09:31:05 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 97D033A659A for ; Thu, 1 Jul 2010 09:31:04 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 18D9368B81 for ; Thu, 1 Jul 2010 16:23:09 +0000 (UTC) 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 beFyG5-b7XXR for ; Thu, 1 Jul 2010 12:22:59 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3DA0B68A8D for ; Thu, 1 Jul 2010 12:22:59 -0400 (EDT) Message-ID: <4C2CC2C6.1010004@htt-consult.com> Date: Thu, 01 Jul 2010 12:31:02 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: hipsec@ietf.org References: <4C2CBE6D.8080800@htt-consult.com> In-Reply-To: <4C2CBE6D.8080800@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Welcome to 5201-bis-02 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, 01 Jul 2010 16:31:12 -0000 At the end of this I have added the changelog that Tobias pointed me to... On 07/01/2010 12:12 PM, Robert Moskowitz wrote: > Tobias Heer with my able assistance, has completed the lastest effort > to move 5201 (and HIP!) to cryto agility and standards track. > > Well I will say that Tobias did most of the writing, but I'll take the > heat on where we went with the changes. Tobias figured out how to add > the crypto agility and avoid some downgrade attacks. I spent time > figuring out how to add ECDSA to the document and changes to KEYMAT. > > There ARE a number of changes, we changed the version number. HIP BEX > still functions as in 5201, but we had to make the Hash negotiable, > add ECDSA, and more Diffie-Hellman options (like ECDH). This resulted > in some interesting changes. > > Tobias, Miika, and I have spent considerable time debating what crypto > suites to include. We are trying to balance agility and compactness. > Should we drop SHA-1 like a hot potato and just specify SHA-256 and > -384 until SHA-3 comes out? Or should SHA-1 still play and we > downplay SHA_384? Or is SHA-384 locked in to meet Suite-B needs? > Which ECDSA key sizes, P160, P256, and P384 seem to be the minimum > (read why for P160). And finally which AES modes (duo modes excluded > for HIP payloads). So please think on this and weigh in with your views. > > First notice the change to the HIT. We realized we need to encode a > HIT_Suite_ID into the HIT. Without this there were a number of > complications and attack options. But this cost us 4 bits from the > hash. We have a limited number of Suite ID slots and are concerned > about how many we eat up right out the door. Note that each hash eats > TWO IDs, one for RSA/DSA and one for ECDSA (also HIP DEX will take one > more). > > The only change to the previous state machine is a transition from > state I1-SENT to I1-SENT - the restart option. An Initiator is > required to restart the HIP exchange if the Responder does not support > the HIT Suite of the Initiator. Note that I have made additional > changes to the state machine in HIP DEX to add aggresive > retransmission. Take a read of that and we can discuss if BEX would > benefit from this feature. > > Next on the the puzzle. Basically we made the size of I and J > variable to the size of the keying needed. Plus the hash is the one > in the HIT_Suite_ID. > > We have added a Diffie-Hellman list into I1. Read the text on what is > going on here. More choices, hints needed, downgrade attacks to avoid. > > HOST_ID parameter got reworked. There is no ECDSA RDATA currently and > the ID is limited to just NIST-ECDSA-256 and NIST-ECDSA-384. We > needed at least BrainpoolP160r1, and perhaps more. So I changed even > the handling of RSA and DSA to be ONLY the specifics from their DNSSEC > RFCs. Then I built up how ECDSA should be handled, using > draft-mcgrew-fundamental-ecc-03.txt. > > The HMAC parameters are renamed MAC, but in 5201 they are still using > HMAC with the hash specified in the HIT-Suite_ID. > > HIP_Transform has been replaced by HIP_Cipher. The hash is locked > down by the HIT_Suite_ID, so the only thing to negotiate is what > cipher will be used for things like the ENCRYPTED parameter. > > I redid KEYMAT to directly use RFC 5869. The changes were slight, but > it puts us using a new standard for hash-based KEYMAT. > > IANA considerations has been increased. > > We need some help with the Appendices;.B and C in particular. > > > Anyway, please start reading. We will collect comments. Those which > are obvious we will incorporate in a -03 to publish just before the > July 12th cutoff date. Others we will organize into discussion points > for the 5201-bis reading gathering. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From rgm@htt-consult.com Thu Jul 1 09:33:02 2010 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 475B93A684A for ; Thu, 1 Jul 2010 09:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=0.869, 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 umVo7WEWoVGu for ; Thu, 1 Jul 2010 09:32:58 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 6C6793A6824 for ; Thu, 1 Jul 2010 09:32:53 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 2A21268B8B for ; Thu, 1 Jul 2010 16:24:58 +0000 (UTC) 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 cbCZLAu1eY-v for ; Thu, 1 Jul 2010 12:24:47 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id DA24668B81 for ; Thu, 1 Jul 2010 12:24:47 -0400 (EDT) Message-ID: <4C2CC333.1070605@htt-consult.com> Date: Thu, 01 Jul 2010 12:32:51 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: hipsec@ietf.org References: <4C2CBE6D.8080800@htt-consult.com> In-Reply-To: <4C2CBE6D.8080800@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Ooops Re: Welcome to 5201-bis-02 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, 01 Jul 2010 16:33:02 -0000 I hit Enter, rather then End... At the end of this I have added the changelog that Tobias pointed me to... On 07/01/2010 12:12 PM, Robert Moskowitz wrote: > Tobias Heer with my able assistance, has completed the lastest effort > to move 5201 (and HIP!) to cryto agility and standards track. > > Well I will say that Tobias did most of the writing, but I'll take the > heat on where we went with the changes. Tobias figured out how to add > the crypto agility and avoid some downgrade attacks. I spent time > figuring out how to add ECDSA to the document and changes to KEYMAT. > > There ARE a number of changes, we changed the version number. HIP BEX > still functions as in 5201, but we had to make the Hash negotiable, > add ECDSA, and more Diffie-Hellman options (like ECDH). This resulted > in some interesting changes. > > Tobias, Miika, and I have spent considerable time debating what crypto > suites to include. We are trying to balance agility and compactness. > Should we drop SHA-1 like a hot potato and just specify SHA-256 and > -384 until SHA-3 comes out? Or should SHA-1 still play and we > downplay SHA_384? Or is SHA-384 locked in to meet Suite-B needs? > Which ECDSA key sizes, P160, P256, and P384 seem to be the minimum > (read why for P160). And finally which AES modes (duo modes excluded > for HIP payloads). So please think on this and weigh in with your views. > > First notice the change to the HIT. We realized we need to encode a > HIT_Suite_ID into the HIT. Without this there were a number of > complications and attack options. But this cost us 4 bits from the > hash. We have a limited number of Suite ID slots and are concerned > about how many we eat up right out the door. Note that each hash eats > TWO IDs, one for RSA/DSA and one for ECDSA (also HIP DEX will take one > more). > > The only change to the previous state machine is a transition from > state I1-SENT to I1-SENT - the restart option. An Initiator is > required to restart the HIP exchange if the Responder does not support > the HIT Suite of the Initiator. Note that I have made additional > changes to the state machine in HIP DEX to add aggresive > retransmission. Take a read of that and we can discuss if BEX would > benefit from this feature. > > Next on the the puzzle. Basically we made the size of I and J > variable to the size of the keying needed. Plus the hash is the one > in the HIT_Suite_ID. > > We have added a Diffie-Hellman list into I1. Read the text on what is > going on here. More choices, hints needed, downgrade attacks to avoid. > > HOST_ID parameter got reworked. There is no ECDSA RDATA currently and > the ID is limited to just NIST-ECDSA-256 and NIST-ECDSA-384. We > needed at least BrainpoolP160r1, and perhaps more. So I changed even > the handling of RSA and DSA to be ONLY the specifics from their DNSSEC > RFCs. Then I built up how ECDSA should be handled, using > draft-mcgrew-fundamental-ecc-03.txt. > > The HMAC parameters are renamed MAC, but in 5201 they are still using > HMAC with the hash specified in the HIT-Suite_ID. > > HIP_Transform has been replaced by HIP_Cipher. The hash is locked > down by the HIT_Suite_ID, so the only thing to negotiate is what > cipher will be used for things like the ENCRYPTED parameter. > > I redid KEYMAT to directly use RFC 5869. The changes were slight, but > it puts us using a new standard for hash-based KEYMAT. > > IANA considerations has been increased. > > We need some help with the Appendices;.B and C in particular. > > > Anyway, please start reading. We will collect comments. Those which > are obvious we will incorporate in a -03 to publish just before the > July 12th cutoff date. Others we will organize into discussion points > for the 5201-bis reading gathering. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > Change-log draft-moskowitz-RFC5201-bis-02 ---------------------------------------- * Included HIT_SUITEs * Renamed OGA list to HIT_SUITE_LIST * Added DH negotiation to I1 and R1 * Added DH_LIST parameter * Added text for DH Group negotiation * Removed second DH public value from DH parameter * Added ECC to HI generation * Added Responder HIT selection to opportunistic mode * Added ECDSA HI text and references (not complete yet) * Added separate section on aborting BEX * Added separate section on downgrade attack prevention * Added text about DH Group selection for use cases without I1 * Removed type range allocation for parameters related to HIP transform types * New type range allocation for parameters that are only covered by a signature if a signature is present (Applies to DH_GROUP_LIST) * Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - hashes are determined by RHASH * The length of I and J for the puzzle now depends on RHASH * New keymat generation * Puzzle seed and solution now use RHASH and have variable length Editorial changes: * Moved timing definitions closer to state machine * Simplified text regarding puzzle lifetime * Clarified the description of the use of I in the puzzle * Removed "Opportunistic mode" description from general definitions. * Some other editorial changes including spelling and consistency of terms * More consistency across the old RFC5201 text. Aligned capitalization and abbreviations. Change-log draft-moskowitz-RFC5201-bis-01 ---------------------------------------- * Extended protocol overview to include restart option * Extended state machine to include restart option because of unsupported Algorithms * Replaced SHA-1 with SHA-256 for required implementation * Added OGA list parameter (715) for detecting the Responder's set of OGAs * Added Appendix on ORCHID use in HITs * Added truncated SHA-256 option for HITs * Added truncated SHA-1 option for HITs * Added text about new ORCHID structure to HIT overview * Moved Editor role to Robert Moskowitz * Added SHA-256 to puzzle parameter * Generalized LTRUNC to be hash-function agnostic * Added text about RHASH depending on OGA From rene.hummen@informatik.rwth-aachen.de Sat Jul 3 15:36:54 2010 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 1046D3A677C for ; Sat, 3 Jul 2010 15:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, 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 5NqPBXRt-l-Y for ; Sat, 3 Jul 2010 15:36:47 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id BEC243A63CB for ; Sat, 3 Jul 2010 15:36:47 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L5000HZV6TAUG80@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Sun, 04 Jul 2010 00:36:46 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,532,1272837600"; d="scan'208";a="63855524" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Sun, 04 Jul 2010 00:36:46 +0200 Received: from [192.168.0.4] ([unknown] [151.59.135.86]) 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 <0L5000FE06T9QE60@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Sun, 04 Jul 2010 00:36:46 +0200 (CEST) From: =?iso-8859-1?Q?Ren=E9_Hummen?= Content-transfer-encoding: quoted-printable Date: Sun, 04 Jul 2010 00:36:44 +0200 Message-id: To: HIP WG X-Mailer: Apple Mail (2.1081) Subject: [Hipsec] Comments on 5201-bis-02 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: Sat, 03 Jul 2010 22:36:54 -0000 Hi everyone, here are my comments/questions regarding RFC 5201-bis-02: - 4.6 Certificate Distribution While I understand the informational reason of having the section "4.5.2 = Sending Data on HIP Packets", I fail to see the reason why section 4.6 = is included in 5201. Specifically, why is there a need to define the = parameter type CERT (768) without further length and value definitions? - 5.2.16 ACK The representation of the parameter only lists a single peer Update ID, = whereas the transmission of multiple IDs is possible. - 5.2.19 - 5.2.22 ECHO_* The definition of these parameters misses eventually required Padding. - 5.3.5 UPDATE Since working on HIPL I am wondering why HIP only defines a single = UPDATE packet. =46rom the perspective of 5201, I can see a conceptually = compelling argument behind this approach, as it allows for a general = purpose packet for the transmission of maintenance information. However, = most extensions using UPDATE that I know of (most noteworthy, ESP = rekeying and mobility and multi-homing) require a 3-way message exchange = to complete their corresponding task. The packets thereby have a = specific order and each of them has specific semantics. Let's take = mobility as an example: (1) notify the peer of an address change, (2) challenge the peer to confirm his new address, and (3) satisfy the challenge. Still, with the current specifications protocol developers are forced to = distinguish between these 3 packets by checking the contained parameter = combinations. This is, in my opinion, more complex than necessary and = error-prone, especially, with respect to the extensibility of the HIP = parameters that can be included in UPDATE packets. So, is there a reason = that prevents us from specifying different maintenance packet types = instead of a single one? Best regards, Ren=E9 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 20772 web: http://ds.rwth-aachen.de/members/hummen From pekka.nikander@nomadiclab.com Sun Jul 4 00:15:07 2010 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 030333A687D for ; Sun, 4 Jul 2010 00:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] 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 NdT6QIr+Bpnt for ; Sun, 4 Jul 2010 00:15:05 -0700 (PDT) Received: from gw.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 7DEC83A67B6 for ; Sun, 4 Jul 2010 00:15:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 989974E6D4; Sun, 4 Jul 2010 10:14:58 +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 CLlZGwl8Y8HO; Sun, 4 Jul 2010 10:14:57 +0300 (EEST) Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id E3CD54E6BF; Sun, 4 Jul 2010 10:14:57 +0300 (EEST) Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id AC4D4106E84; Sun, 4 Jul 2010 10:14:57 +0300 (EEST) Received: from [IPv6:::1] (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id 5D56A106E83; Sun, 4 Jul 2010 10:14:57 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Pekka Nikander In-Reply-To: Date: Sun, 4 Jul 2010 10:14:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com> References: To: =?iso-8859-1?Q?Ren=E9_Hummen?= X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: ClamAV using ClamSMTP Cc: HIP WG Subject: Re: [Hipsec] Comments on 5201-bis-02 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: Sun, 04 Jul 2010 07:15:07 -0000 > - 5.3.5 UPDATE > Since working on HIPL I am wondering why HIP only defines a single = UPDATE packet. =46rom the perspective of 5201, I can see a conceptually = compelling argument behind this approach, as it allows for a general = purpose packet for the transmission of maintenance information. However, = most extensions using UPDATE that I know of (most noteworthy, ESP = rekeying and mobility and multi-homing) require a 3-way message exchange = to complete their corresponding task. The packets thereby have a = specific order and each of them has specific semantics. Let's take = mobility as an example: > (1) notify the peer of an address change, > (2) challenge the peer to confirm his new address, and > (3) satisfy the challenge. > Still, with the current specifications protocol developers are forced = to distinguish between these 3 packets by checking the contained = parameter combinations. This is, in my opinion, more complex than = necessary and error-prone, especially, with respect to the extensibility = of the HIP parameters that can be included in UPDATE packets. So, is = there a reason that prevents us from specifying different maintenance = packet types instead of a single one? The original idea was that UPDATEs would just be a "carrier" for upper = level protocols, allowing upper level protocols to be mixed and matched = on individual packets. E.g. so that you could run a mobility exchange = and ESP rekeying at the same time, with the same packets. E.g. A->B: Notify address change B->A: Challenge address; Initiate ESP rekeying A->B: Send the challenge response; Continue ESP rekeying etc. But since I haven't been involved in implementation efforts for the last = N years, I don't know if the current implementations support such = behaviour --Pekka From mkomu@cs.hut.fi Sun Jul 4 03:12:31 2010 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 B0FBD3A688D for ; Sun, 4 Jul 2010 03:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 ReGxFQQi8Oad for ; Sun, 4 Jul 2010 03:12:30 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 70B333A67CF for ; Sun, 4 Jul 2010 03:12:30 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1OVMBY-00077p-MG for hipsec@ietf.org; Sun, 04 Jul 2010 13:12:29 +0300 Message-ID: <4C305E89.10208@cs.hut.fi> Date: Sun, 04 Jul 2010 13:12:25 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100422 Shredder/3.0.5pre MIME-Version: 1.0 To: hipsec@ietf.org References: <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com> In-Reply-To: <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Comments on 5201-bis-02 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: Sun, 04 Jul 2010 10:12:31 -0000 On 07/04/2010 10:14 AM, Pekka Nikander wrote: Hi Pekka and Rene, >> - 5.3.5 UPDATE >> Since working on HIPL I am wondering why HIP only defines a single UPDATE packet. From the perspective of 5201, I can see a conceptually compelling argument behind this approach, as it allows for a general purpose packet for the transmission of maintenance information. However, most extensions using UPDATE that I know of (most noteworthy, ESP rekeying and mobility and multi-homing) require a 3-way message exchange to complete their corresponding task. The packets thereby have a specific order and each of them has specific semantics. Let's take mobility as an example: >> (1) notify the peer of an address change, >> (2) challenge the peer to confirm his new address, and >> (3) satisfy the challenge. >> Still, with the current specifications protocol developers are forced to distinguish between these 3 packets by checking the contained parameter combinations. This is, in my opinion, more complex than necessary and error-prone, especially, with respect to the extensibility of the HIP parameters that can be included in UPDATE packets. So, is there a reason that prevents us from specifying different maintenance packet types instead of a single one? > > The original idea was that UPDATEs would just be a "carrier" for upper level protocols, allowing upper level protocols to be mixed and matched on individual packets. E.g. so that you could run a mobility exchange and ESP rekeying at the same time, with the same packets. E.g. > > A->B: Notify address change > B->A: Challenge address; Initiate ESP rekeying > A->B: Send the challenge response; Continue ESP rekeying > etc. > > But since I haven't been involved in implementation efforts for the last N years, I don't know if the current implementations support such behaviour the carrier statement is still valid but UPDATE but I doubt if it's utilized much. I think relabeling the UPDATE control headers would be ok even with simultaneous rekeying but please correct if I'm wrong. Seems like registration as defined in RFC5203 would work still nicely with relabeled UPDATEs. From thomas.r.henderson@boeing.com Sun Jul 4 21:08:07 2010 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 3EF213A687C for ; Sun, 4 Jul 2010 21:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.305 X-Spam-Level: X-Spam-Status: No, score=-5.305 tagged_above=-999 required=5 tests=[AWL=0.994, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 89xbSkRqcj3a for ; Sun, 4 Jul 2010 21:08:06 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 60E163A687B for ; Sun, 4 Jul 2010 21:08:06 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o6548028001750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Jul 2010 21:08:01 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o65480dn001872; Sun, 4 Jul 2010 21:08:00 -0700 (PDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o6547xQT001863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 4 Jul 2010 21:07:59 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Sun, 4 Jul 2010 21:07:59 -0700 From: "Henderson, Thomas R" To: "'Pekka Nikander'" , =?iso-8859-1?Q?Ren=E9_Hummen?= Date: Sun, 4 Jul 2010 21:07:57 -0700 Thread-Topic: [Hipsec] Comments on 5201-bis-02 Thread-Index: AcsbSKRoiJY6LKuIRe2JdRrGxm1cmgArpEQQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE97163BB@XCH-NW-10V.nw.nos.boeing.com> References: <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com> In-Reply-To: <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP WG Subject: Re: [Hipsec] Comments on 5201-bis-02 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, 05 Jul 2010 04:08:07 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Pekka Nikander > Sent: Sunday, July 04, 2010 12:15 AM > To: Ren=E9 Hummen > Cc: HIP WG > Subject: Re: [Hipsec] Comments on 5201-bis-02 > > > - 5.3.5 UPDATE > > Since working on HIPL I am wondering why HIP only defines a > single UPDATE packet. From the perspective of 5201, I can see > a conceptually compelling argument behind this approach, as > it allows for a general purpose packet for the transmission > of maintenance information. However, most extensions using > UPDATE that I know of (most noteworthy, ESP rekeying and > mobility and multi-homing) require a 3-way message exchange > to complete their corresponding task. The packets thereby > have a specific order and each of them has specific > semantics. Let's take mobility as an example: > > (1) notify the peer of an address change, > > (2) challenge the peer to confirm his new address, and > > (3) satisfy the challenge. > > Still, with the current specifications protocol developers > are forced to distinguish between these 3 packets by checking > the contained parameter combinations. This is, in my opinion, > more complex than necessary and error-prone, especially, with > respect to the extensibility of the HIP parameters that can > be included in UPDATE packets. So, is there a reason that > prevents us from specifying different maintenance packet > types instead of a single one? > > The original idea was that UPDATEs would just be a "carrier" > for upper level protocols, allowing upper level protocols to > be mixed and matched on individual packets. E.g. so that you > could run a mobility exchange and ESP rekeying at the same > time, with the same packets. E.g. > > A->B: Notify address change > B->A: Challenge address; Initiate ESP rekeying > A->B: Send the challenge response; Continue ESP rekeying > etc. > > But since I haven't been involved in implementation efforts > for the last N years, I don't know if the current > implementations support such behaviour > I tend to agree with Rene's observations and think it would be worthwhile t= o examine his proposal in the new protocol version. I am curious how often= the implementations actually couple the rekeying with address change notif= ications in practice. - Tom From mkomu@cs.hut.fi Sun Jul 4 23:49:53 2010 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 129CE3A6902 for ; Sun, 4 Jul 2010 23:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.850, 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 B8zOoWwyjh-A for ; Sun, 4 Jul 2010 23:49:52 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 322D83A6905 for ; Sun, 4 Jul 2010 23:49:52 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1OVfV2-0003WW-PC for hipsec@ietf.org; Mon, 05 Jul 2010 09:49:52 +0300 Message-ID: <4C318090.7080507@cs.hut.fi> Date: Mon, 05 Jul 2010 09:49:52 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100422 Shredder/3.0.5pre MIME-Version: 1.0 To: hipsec@ietf.org References: <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4CE97163BB@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CE97163BB@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Hipsec] Comments on 5201-bis-02 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, 05 Jul 2010 06:49:53 -0000 On 07/05/2010 07:07 AM, Henderson, Thomas R wrote: Hi Tom, >> -----Original Message----- >> From: hipsec-bounces@ietf.org >> [mailto:hipsec-bounces@ietf.org] On Behalf Of Pekka Nikander >> Sent: Sunday, July 04, 2010 12:15 AM >> To: René Hummen >> Cc: HIP WG >> Subject: Re: [Hipsec] Comments on 5201-bis-02 >> >>> - 5.3.5 UPDATE >>> Since working on HIPL I am wondering why HIP only defines a >> single UPDATE packet. From the perspective of 5201, I can see >> a conceptually compelling argument behind this approach, as >> it allows for a general purpose packet for the transmission >> of maintenance information. However, most extensions using >> UPDATE that I know of (most noteworthy, ESP rekeying and >> mobility and multi-homing) require a 3-way message exchange >> to complete their corresponding task. The packets thereby >> have a specific order and each of them has specific >> semantics. Let's take mobility as an example: >>> (1) notify the peer of an address change, >>> (2) challenge the peer to confirm his new address, and >>> (3) satisfy the challenge. >>> Still, with the current specifications protocol developers >> are forced to distinguish between these 3 packets by checking >> the contained parameter combinations. This is, in my opinion, >> more complex than necessary and error-prone, especially, with >> respect to the extensibility of the HIP parameters that can >> be included in UPDATE packets. So, is there a reason that >> prevents us from specifying different maintenance packet >> types instead of a single one? >> >> The original idea was that UPDATEs would just be a "carrier" >> for upper level protocols, allowing upper level protocols to >> be mixed and matched on individual packets. E.g. so that you >> could run a mobility exchange and ESP rekeying at the same >> time, with the same packets. E.g. >> >> A->B: Notify address change >> B->A: Challenge address; Initiate ESP rekeying >> A->B: Send the challenge response; Continue ESP rekeying >> etc. >> >> But since I haven't been involved in implementation efforts >> for the last N years, I don't know if the current >> implementations support such behaviour >> > > I tend to agree with Rene's observations and think it would be worthwhile to examine his proposal in the new protocol version. I am curious how often the implementations actually couple the rekeying with address change notifications in practice. this hasn't been the case at least in HIPL. From jan.melen@nomadiclab.com Tue Jul 6 06:37:53 2010 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 A69183A690C for ; Tue, 6 Jul 2010 06:37:53 -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=[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 b+AHL62kw6Ga for ; Tue, 6 Jul 2010 06:37:52 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 4C96B3A68FA for ; Tue, 6 Jul 2010 06:37:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 161EC4E6E4; Tue, 6 Jul 2010 16:37:51 +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 hP0huvsi6t8Q; Tue, 6 Jul 2010 16:37:49 +0300 (EEST) Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id 26B654E6C8; Tue, 6 Jul 2010 16:37:49 +0300 (EEST) Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id DCBF3106E84; Tue, 6 Jul 2010 16:37:48 +0300 (EEST) Received: from [IPv6:::1] (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id A2CED106E83; Tue, 6 Jul 2010 16:37:48 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Jan Melen In-Reply-To: <4C318090.7080507@cs.hut.fi> Date: Tue, 6 Jul 2010 16:37:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4CE97163BB@XCH-NW-10V.nw.nos.boeing.com> <4C318090.7080507@cs.hut.fi> To: Miika Komu X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: ClamAV using ClamSMTP Cc: hipsec@ietf.org Subject: Re: [Hipsec] Comments on 5201-bis-02 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, 06 Jul 2010 13:37:54 -0000 On Jul 5, 2010, at 9:49 AM, Miika Komu wrote: > On 07/05/2010 07:07 AM, Henderson, Thomas R wrote: >=20 > Hi Tom, >=20 >>> -----Original Message----- >>> From: hipsec-bounces@ietf.org >>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Pekka Nikander >>> Sent: Sunday, July 04, 2010 12:15 AM >>> To: Ren=E9 Hummen >>> Cc: HIP WG >>> Subject: Re: [Hipsec] Comments on 5201-bis-02 >>>=20 >>>> - 5.3.5 UPDATE >>>> Since working on HIPL I am wondering why HIP only defines a >>> single UPDATE packet. =46rom the perspective of 5201, I can see >>> a conceptually compelling argument behind this approach, as >>> it allows for a general purpose packet for the transmission >>> of maintenance information. However, most extensions using >>> UPDATE that I know of (most noteworthy, ESP rekeying and >>> mobility and multi-homing) require a 3-way message exchange >>> to complete their corresponding task. The packets thereby >>> have a specific order and each of them has specific >>> semantics. Let's take mobility as an example: >>>> (1) notify the peer of an address change, >>>> (2) challenge the peer to confirm his new address, and >>>> (3) satisfy the challenge. >>>> Still, with the current specifications protocol developers >>> are forced to distinguish between these 3 packets by checking >>> the contained parameter combinations. This is, in my opinion, >>> more complex than necessary and error-prone, especially, with >>> respect to the extensibility of the HIP parameters that can >>> be included in UPDATE packets. So, is there a reason that >>> prevents us from specifying different maintenance packet >>> types instead of a single one? >>>=20 >>> The original idea was that UPDATEs would just be a "carrier" >>> for upper level protocols, allowing upper level protocols to >>> be mixed and matched on individual packets. E.g. so that you >>> could run a mobility exchange and ESP rekeying at the same >>> time, with the same packets. E.g. >>>=20 >>> A->B: Notify address change >>> B->A: Challenge address; Initiate ESP rekeying >>> A->B: Send the challenge response; Continue ESP rekeying >>> etc. >>>=20 >>> But since I haven't been involved in implementation efforts >>> for the last N years, I don't know if the current >>> implementations support such behaviour >>>=20 >>=20 >> I tend to agree with Rene's observations and think it would be = worthwhile to examine his proposal in the new protocol version. I am = curious how often the implementations actually couple the rekeying with = address change notifications in practice. >=20 > this hasn't been the case at least in HIPL. And the opposite, that has been the case for HIP4inter.net. :-) Jan From ari.keranen@nomadiclab.com Tue Jul 6 06:50:20 2010 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 122553A6870 for ; Tue, 6 Jul 2010 06:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 zfGH-mxahp1a for ; Tue, 6 Jul 2010 06:50:19 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id D09FE3A67AE for ; Tue, 6 Jul 2010 06:50:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 7FB9B4E6E6 for ; Tue, 6 Jul 2010 16:50:19 +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 V38V73662DoP for ; Tue, 6 Jul 2010 16:50:18 +0300 (EEST) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 889B74E6E5 for ; Tue, 6 Jul 2010 16:50:18 +0300 (EEST) Message-ID: <4C33349A.7020904@nomadiclab.com> Date: Tue, 06 Jul 2010 16:50:18 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: HIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Clarifying HIP parameter type ranges 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, 06 Jul 2010 13:50:20 -0000 Hi all, I think we should clarify, at least for the 5201bis, how new HIP parameter type values should be assigned. The current text at the end of section 5.2 of 5201 tries to do that, but it is not really accurate, and in some places even wrong (I filed errata about that a year ago). Here's what is says: Parameters numbered between 0-1023 are used in HIP handshake and update procedures and are covered by signatures. Parameters numbered between 1024-2047 are reserved. Parameters numbered between 2048-4095 are used for parameters related to HIP transform types. Parameters numbered between 4096 and (2^16 - 2^12) 61439 are reserved. Parameters numbered between 61440-62463 are used for signatures and signed MACs. Parameters numbered between 62464- 63487 are used for parameters that fall outside of the signed area of the packet. Parameters numbered between 63488-64511 are used for rendezvous and other relaying services. Parameters numbered between 64512-65535 are reserved. I talked about this with Jan, and we were thinking that for the first range (0-1023) it could make sense to rather say something like: "Parameters that are important for basic HIP functionality and thus should be implemented by all HIP implementations." For the reserved ranges, it should be mentioned for what purpose are they reserved (for future versions of HIP?). For extensions that are not "basic functionality" there should be explicitly mentioned ranges for both signed and unsigned parameter values. Also, it would be good to recommend semantic grouping for new parameters, i.e., parameters with similar purpose would be close to each other. Another question is should one start new sets from binary or decimal value boundaries; I'm personally inclined to start from decimal value boundaries (e.g., 32800 instead of 32768) And the IANA page [1] should be updated with the ranges; at least for the reserved parts. Opinions? Cheers, Ari [1] http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-3 From heer@informatik.rwth-aachen.de Thu Jul 8 14:12:44 2010 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 9CA363A689C for ; Thu, 8 Jul 2010 14:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 w2D5lEppLmEQ for ; Thu, 8 Jul 2010 14:12:42 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 987F13A68F3 for ; Thu, 8 Jul 2010 14:12:41 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L5900CYBC99FI40@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 08 Jul 2010 23:12:45 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,560,1272837600"; d="scan'208";a="64532352" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 08 Jul 2010 23:12:45 +0200 Received: from coyote.lan ([unknown] [91.179.47.138]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L5900BCVC98MT50@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 08 Jul 2010 23:12:44 +0200 (CEST) From: Tobias Heer In-reply-to: <4C33349A.7020904@nomadiclab.com> Date: Thu, 08 Jul 2010 23:12:48 +0200 Message-id: <5F1221F0-C61C-4801-B3C5-CF48A655257B@cs.rwth-aachen.de> References: <4C33349A.7020904@nomadiclab.com> To: HIP WG X-Mailer: Apple Mail (2.1081) Subject: Re: [Hipsec] Clarifying HIP parameter type ranges 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, 08 Jul 2010 21:12:44 -0000 Hello Ari, Am 06.07.2010 um 15:50 schrieb Ari Keranen: > Hi all, > > I think we should clarify, at least for the 5201bis, how new HIP parameter type values should be assigned. The current text at the end of section 5.2 of 5201 tries to do that, but it is not really accurate, and in some places even wrong (I filed errata about that a year ago). Here's what is says: > > Parameters numbered between 0-1023 are used in HIP > handshake and update procedures and are covered by signatures. > Parameters numbered between 1024-2047 are reserved. Parameters > numbered between 2048-4095 are used for parameters related to HIP > transform types. Parameters numbered between 4096 and (2^16 - 2^12) > 61439 are reserved. Parameters numbered between 61440-62463 are used > for signatures and signed MACs. Parameters numbered between 62464- > 63487 are used for parameters that fall outside of the signed area of > the packet. Parameters numbered between 63488-64511 are used for > rendezvous and other relaying services. Parameters numbered between > 64512-65535 are reserved. > > I talked about this with Jan, and we were thinking that for the first range (0-1023) it could make sense to rather say something like: > "Parameters that are important for basic HIP functionality and thus should be implemented by all HIP implementations." > > For the reserved ranges, it should be mentioned for what purpose are they reserved (for future versions of HIP?). > > For extensions that are not "basic functionality" there should be explicitly mentioned ranges for both signed and unsigned parameter values. That works as long as you keep the signed and non-signed parts of the packet apart. Right now signature handling is quite simple and elegant. Therefore at least the fact that parameters with numbers smaller than x will be signed and the osthers won't. I agree that the ranges could be more useful. We already did some reshaping by removing the transform-related range. However, I would like to keep existing type numbers i possible (and sensible). Tobias > > Also, it would be good to recommend semantic grouping for new parameters, i.e., parameters with similar purpose would be close to each other. Another question is should one start new sets from binary or decimal value boundaries; I'm personally inclined to start from decimal value boundaries (e.g., 32800 instead of 32768) > > And the IANA page [1] should be updated with the ranges; at least for the reserved parts. > > Opinions? > > > Cheers, > Ari > > > [1] http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-3 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From ari.keranen@nomadiclab.com Fri Jul 9 01:59:00 2010 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 DDBAB3A696F for ; Fri, 9 Jul 2010 01:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 NcYp-oXddU1j for ; Fri, 9 Jul 2010 01:58:59 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 2B3333A6856 for ; Fri, 9 Jul 2010 01:58:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6C8444E6C1; Fri, 9 Jul 2010 11:59:03 +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 QWbz1Xdgn3Hi; Fri, 9 Jul 2010 11:59:02 +0300 (EEST) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 95E6D4E548; Fri, 9 Jul 2010 11:59:02 +0300 (EEST) Message-ID: <4C36E4D6.1070206@nomadiclab.com> Date: Fri, 09 Jul 2010 11:59:02 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Tobias Heer References: <4C33349A.7020904@nomadiclab.com> <5F1221F0-C61C-4801-B3C5-CF48A655257B@cs.rwth-aachen.de> In-Reply-To: <5F1221F0-C61C-4801-B3C5-CF48A655257B@cs.rwth-aachen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] Clarifying HIP parameter type ranges 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, 09 Jul 2010 08:59:01 -0000 Hi Tobias, On 07/09/2010 12:12 AM, Tobias Heer wrote: > Hello Ari, Am 06.07.2010 um 15:50 schrieb Ari Keranen: > >> Hi all, >> >> I think we should clarify, at least for the 5201bis, how new HIP >> parameter type values should be assigned. The current text at the >> end of section 5.2 of 5201 tries to do that, but it is not really >> accurate, and in some places even wrong (I filed errata about that >> a year ago). Here's what is says: >> >> Parameters numbered between 0-1023 are used in HIP handshake and >> update procedures and are covered by signatures. Parameters >> numbered between 1024-2047 are reserved. Parameters numbered >> between 2048-4095 are used for parameters related to HIP transform >> types. Parameters numbered between 4096 and (2^16 - 2^12) 61439 >> are reserved. Parameters numbered between 61440-62463 are used for >> signatures and signed MACs. Parameters numbered between 62464- >> 63487 are used for parameters that fall outside of the signed area >> of the packet. Parameters numbered between 63488-64511 are used >> for rendezvous and other relaying services. Parameters numbered >> between 64512-65535 are reserved. >> >> I talked about this with Jan, and we were thinking that for the >> first range (0-1023) it could make sense to rather say something >> like: "Parameters that are important for basic HIP functionality >> and thus should be implemented by all HIP implementations." >> >> For the reserved ranges, it should be mentioned for what purpose >> are they reserved (for future versions of HIP?). >> >> For extensions that are not "basic functionality" there should be >> explicitly mentioned ranges for both signed and unsigned parameter >> values. > > That works as long as you keep the signed and non-signed parts of the > packet apart. Right now signature handling is quite simple and > elegant. Therefore at least the fact that parameters with numbers > smaller than x will be signed and the osthers won't. > > I agree that the ranges could be more useful. We already did some > reshaping by removing the transform-related range. However, I would > like to keep existing type numbers i possible (and sensible). I think the current way is technically good and I would not touch the parameter values or other technical details, but rather add some more explicit text to the draft (or modify the existing) giving hints where new parameter values should be inserted. Also, table representation instead of plain text could be better for that part of the text. Cheers, Ari > Tobias > > >> Also, it would be good to recommend semantic grouping for new >> parameters, i.e., parameters with similar purpose would be close to >> each other. Another question is should one start new sets from >> binary or decimal value boundaries; I'm personally inclined to >> start from decimal value boundaries (e.g., 32800 instead of 32768) > >> And the IANA page [1] should be updated with the ranges; at least >> for the reserved parts. >> >> Opinions? >> >> >> Cheers, Ari >> >> >> [1] >> http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-3 From root@core3.amsl.com Fri Jul 9 03:00:02 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4AA573A6986; Fri, 9 Jul 2010 03:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100709100002.4AA573A6986@core3.amsl.com> Date: Fri, 9 Jul 2010 03:00:02 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-hiccups-03.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: Fri, 09 Jul 2010 10:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS) Author(s) : G. Camarillo, J. Melen Filename : draft-ietf-hip-hiccups-03.txt Pages : 17 Date : 2010-07-09 This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-hiccups-03.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-hiccups-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-09025418.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 05:45:02 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DC3313A689E; Mon, 12 Jul 2010 05:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712124501.DC3313A689E@core3.amsl.com> Date: Mon, 12 Jul 2010 05:45:01 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-hiccups-04.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: Mon, 12 Jul 2010 12:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS) Author(s) : G. Camarillo, J. Melen Filename : draft-ietf-hip-hiccups-04.txt Pages : 17 Date : 2010-07-12 This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-hiccups-04.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-hiccups-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12053043.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 08:30:53 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2449B3A6957; Mon, 12 Jul 2010 08:30:21 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712153038.2449B3A6957@core3.amsl.com> Date: Mon, 12 Jul 2010 08:30:22 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-reload-instance-02.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: Mon, 12 Jul 2010 15:30:56 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) Author(s) : A. Keranen, et al. Filename : draft-ietf-hip-reload-instance-02.txt Pages : 10 Date : 2010-07-12 This document is the Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-reload-instance-02.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-reload-instance-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12082559.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 08:30:56 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 761743A69A9; Mon, 12 Jul 2010 08:30:19 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712153053.761743A69A9@core3.amsl.com> Date: Mon, 12 Jul 2010 08:30:19 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-over-hip-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: Mon, 12 Jul 2010 15:30:57 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Signaling Message Transport Modes Author(s) : A. Keranen Filename : draft-ietf-hip-over-hip-01.txt Pages : 9 Date : 2010-07-12 This document specifies two transport modes for Host Identity Protocol signaling messages that allow conveying them over encrypted connections initiated with the Host Identity Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-over-hip-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12082109.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Mon Jul 12 08:39:50 2010 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 31F403A699F for ; Mon, 12 Jul 2010 08:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 e+W0kzbRJCAX for ; Mon, 12 Jul 2010 08:39:49 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 2F04C3A6B42 for ; Mon, 12 Jul 2010 08:39:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 157FE4E6E1 for ; Mon, 12 Jul 2010 18:39:51 +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 55Squ+YiRzxh for ; Mon, 12 Jul 2010 18:39:50 +0300 (EEST) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 843DF4E6C1 for ; Mon, 12 Jul 2010 18:39:50 +0300 (EEST) Message-ID: <4C3B3746.3080207@nomadiclab.com> Date: Mon, 12 Jul 2010 18:39:50 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: hipsec@ietf.org References: <20100712153038.2449B3A6957@core3.amsl.com> In-Reply-To: <20100712153038.2449B3A6957@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-reload-instance-02.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: Mon, 12 Jul 2010 15:39:50 -0000 Hi all, This version updates the configuration document part to match with what is defined in the latest RELOAD specification. In addition there are some editorial fixes and clarification. Cheers, Ari On 07/12/2010 06:30 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > > Title : Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) > Author(s) : A. Keranen, et al. > Filename : draft-ietf-hip-reload-instance-02.txt > Pages : 10 > Date : 2010-07-12 > > This document is the Host Identity Protocol-Based Overlay Networking > Environment (HIP BONE) instance specification for the REsource > LOcation And Discovery (RELOAD) protocol. The document provides the > details needed to build a RELOAD-based overlay that uses HIP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-reload-instance-02.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. From ari.keranen@nomadiclab.com Mon Jul 12 08:42:31 2010 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 AA30E3A63EC for ; Mon, 12 Jul 2010 08:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 GA8El0Fz4IAe for ; Mon, 12 Jul 2010 08:42:30 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 245D53A6986 for ; Mon, 12 Jul 2010 08:42:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 7B45E4E6DC for ; Mon, 12 Jul 2010 18:42:34 +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 pGitPVZ1k06a for ; Mon, 12 Jul 2010 18:42:33 +0300 (EEST) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id A4F474E6C1 for ; Mon, 12 Jul 2010 18:42:33 +0300 (EEST) Message-ID: <4C3B37E9.7050202@nomadiclab.com> Date: Mon, 12 Jul 2010 18:42:33 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: hipsec@ietf.org References: <20100712153053.761743A69A9@core3.amsl.com> In-Reply-To: <20100712153053.761743A69A9@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-over-hip-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: Mon, 12 Jul 2010 15:42:32 -0000 The only technical change in this version is the new type value for the HIP_TRANSPORT_MODE parameter. The value used to be 990, but as discussed in the other thread, it's better to use values above 1023 for this kind of extensions, and thus value 7680 was chosen instead. Cheers, Ari On 07/12/2010 06:30 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > > Title : Host Identity Protocol Signaling Message Transport Modes > Author(s) : A. Keranen > Filename : draft-ietf-hip-over-hip-01.txt > Pages : 9 > Date : 2010-07-12 > > This document specifies two transport modes for Host Identity > Protocol signaling messages that allow conveying them over encrypted > connections initiated with the Host Identity Protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-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. From root@core3.amsl.com Mon Jul 12 11:00:02 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 575803A6BB1; Mon, 12 Jul 2010 11:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712180002.575803A6BB1@core3.amsl.com> Date: Mon, 12 Jul 2010 11:00:02 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-hiccups-05.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: Mon, 12 Jul 2010 18:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS) Author(s) : G. Camarillo, J. Melen Filename : draft-ietf-hip-hiccups-05.txt Pages : 17 Date : 2010-07-12 This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-hiccups-05.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-hiccups-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12105436.I-D@ietf.org> --NextPart-- From jan.melen@nomadiclab.com Mon Jul 12 11:02:44 2010 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 282D13A6BE1 for ; Mon, 12 Jul 2010 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 mYuogzfK-+Ce for ; Mon, 12 Jul 2010 11:02:42 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id F02813A6BC6 for ; Mon, 12 Jul 2010 11:02:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id ECC164E6DC for ; Mon, 12 Jul 2010 21:02:42 +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 9e-lO2KGVwdQ for ; Mon, 12 Jul 2010 21:02:42 +0300 (EEST) Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id F28954E6C1 for ; Mon, 12 Jul 2010 21:02:41 +0300 (EEST) Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id B9CBA106EA4 for ; Mon, 12 Jul 2010 21:02:41 +0300 (EEST) Received: from [IPv6:::1] (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id 6D30A106E83 for ; Mon, 12 Jul 2010 21:02:41 +0300 (EEST) From: Jan Melen Content-Type: multipart/alternative; boundary=Apple-Mail-5-2850518 Date: Mon, 12 Jul 2010 21:02:41 +0300 References: <20100712124502.4B25A3A68AD@core3.amsl.com> To: HIP Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Hipsec] Fwd: I-D Action:draft-jokela-hip-rfc5202-bis-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: Mon, 12 Jul 2010 18:02:44 -0000 --Apple-Mail-5-2850518 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, -02 with updated crypto algorithms and mandatory to implement = algorithms. Additionally, some small update on Appendix B BEET mode = ipsec. Regards, Jan Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: July 12, 2010 3:45:02 PM GMT+03:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-jokela-hip-rfc5202-bis-01.txt=20 > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Using the Encapsulating Security Payload (ESP) = Transport Format with the Host Identity Protocol (HIP) > Author(s) : P. Jokela, et al. > Filename : draft-jokela-hip-rfc5202-bis-01.txt > Pages : 37 > Date : 2010-07-11 >=20 > This memo specifies an Encapsulated Security Payload (ESP) based > mechanism for transmission of user data packets, to be used with the > Host Identity Protocol (HIP). >=20 > IESG Note >=20 > The following issues describe IESG concerns about this document. The > IESG expects that these issues will be addressed when future versions > of HIP are designed. >=20 > In case of complex Security Policy Databases (SPDs) and the co- > existence of HIP and security-related protocols such as IKE, > implementors may encounter conditions that are unspecified in these > documents. For example, when the SPD defines an IP address subnet to > be protected and a HIP host is residing in that IP address area, > there is a possibility that the communication is encrypted multiple > times. Readers are advised to pay special attention when running HIP > with complex SPD settings. Future specifications should clearly > define when multiple encryption is intended, and when it should be > avoided. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-jokela-hip-rfc5202-bis-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > 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-5-2850518 Content-Type: multipart/mixed; boundary=Apple-Mail-6-2850519 --Apple-Mail-6-2850519 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: July 12, 2010 3:45:02 PM = GMT+03:00
Subject: I-D = Action:draft-jokela-hip-rfc5202-bis-01.txt
Reply-To: internet-drafts@ietf.org
<= /span>

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

Title =           : Using the = Encapsulating Security Payload (ESP) Transport Format with the Host = Identity Protocol (HIP)
Author(s) =       : P. Jokela, et al.
Filename =        : = draft-jokela-hip-rfc5202-bis-01.txt
Pages =           : = 37
= Date =            : = 2010-07-11

This memo specifies an Encapsulated Security Payload = (ESP) based
mechanism for transmission of user data packets, to be = used with the
Host Identity Protocol (HIP).

IESG = Note

The following issues describe IESG concerns about this = document.  The
IESG expects that these issues will be addressed = when future versions
of HIP are designed.

In case of complex = Security Policy Databases (SPDs) and the co-
existence of HIP and = security-related protocols such as IKE,
implementors may encounter = conditions that are unspecified in these
documents.  For = example, when the SPD defines an IP address subnet to
be protected = and a HIP host is residing in that IP address area,
there is a = possibility that the communication is encrypted multiple
times. =  Readers are advised to pay special attention when running = HIP
with complex SPD settings.  Future specifications should = clearly
define when multiple encryption is intended, and when it = should be
avoided.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jokela-hip-rfc5202-bis-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-6-2850519 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2010-07-12053313.I-D@ietf.org>

--Apple-Mail-6-2850519 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-6-2850519-- --Apple-Mail-5-2850518-- From jan.melen@nomadiclab.com Mon Jul 12 11:41:03 2010 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 B0F3D3A6C08 for ; Mon, 12 Jul 2010 11:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 aSHUKXuXVRSx for ; Mon, 12 Jul 2010 11:41:02 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 1A24C3A6C0B for ; Mon, 12 Jul 2010 11:41:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 8DAF94E6DC for ; Mon, 12 Jul 2010 21:41:09 +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 i1zC6jtevwdv for ; Mon, 12 Jul 2010 21:41:08 +0300 (EEST) Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id D32B64E6C1 for ; Mon, 12 Jul 2010 21:41:08 +0300 (EEST) Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id 9A035106EA5 for ; Mon, 12 Jul 2010 21:41:08 +0300 (EEST) Received: from [IPv6:::1] (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id 5946E106EA4 for ; Mon, 12 Jul 2010 21:41:08 +0300 (EEST) From: Jan Melen Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-8-5157338 Date: Mon, 12 Jul 2010 21:41:07 +0300 In-Reply-To: To: HIP References: <20100712124502.4B25A3A68AD@core3.amsl.com> Message-Id: X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [Hipsec] Fwd: I-D Action:draft-jokela-hip-rfc5202-bis-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: Mon, 12 Jul 2010 18:41:03 -0000 --Apple-Mail-8-5157338 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, And the version of course is -01, but send comments so we can get also = -02 out :-) On Jul 12, 2010, at 9:02 PM, Jan Melen wrote: > Hi, >=20 > -02 with updated crypto algorithms and mandatory to implement = algorithms. Additionally, some small update on Appendix B BEET mode = ipsec. >=20 > Regards, > Jan >=20 > Begin forwarded message: >=20 >> From: Internet-Drafts@ietf.org >> Date: July 12, 2010 3:45:02 PM GMT+03:00 >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-jokela-hip-rfc5202-bis-01.txt=20 >> Reply-To: internet-drafts@ietf.org >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >> Title : Using the Encapsulating Security Payload (ESP) = Transport Format with the Host Identity Protocol (HIP) >> Author(s) : P. Jokela, et al. >> Filename : draft-jokela-hip-rfc5202-bis-01.txt >> Pages : 37 >> Date : 2010-07-11 >>=20 >> This memo specifies an Encapsulated Security Payload (ESP) based >> mechanism for transmission of user data packets, to be used with the >> Host Identity Protocol (HIP). >>=20 >> IESG Note >>=20 >> The following issues describe IESG concerns about this document. The >> IESG expects that these issues will be addressed when future versions >> of HIP are designed. >>=20 >> In case of complex Security Policy Databases (SPDs) and the co- >> existence of HIP and security-related protocols such as IKE, >> implementors may encounter conditions that are unspecified in these >> documents. For example, when the SPD defines an IP address subnet to >> be protected and a HIP host is residing in that IP address area, >> there is a possibility that the communication is encrypted multiple >> times. Readers are advised to pay special attention when running HIP >> with complex SPD settings. Future specifications should clearly >> define when multiple encryption is intended, and when it should be >> avoided. >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-jokela-hip-rfc5202-bis-01.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> 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 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --Apple-Mail-8-5157338 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

-02 with = updated crypto algorithms and mandatory to implement algorithms. = Additionally, some small update on Appendix B BEET mode = ipsec.

   = Regards,
     Jan

Begin = forwarded message:

Date: July 12, 2010 3:45:02 PM = GMT+03:00
Subject: I-D = Action:draft-jokela-hip-rfc5202-bis-01.txt
Reply-To: internet-drafts@ietf.org
<= /span>

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

Title =           : Using the = Encapsulating Security Payload (ESP) Transport Format with the Host = Identity Protocol (HIP)
Author(s) =       : P. Jokela, et al.
Filename =        : = draft-jokela-hip-rfc5202-bis-01.txt
Pages =           : = 37
= Date =            : = 2010-07-11

This memo specifies an Encapsulated Security Payload = (ESP) based
mechanism for transmission of user data packets, to be = used with the
Host Identity Protocol (HIP).

IESG = Note

The following issues describe IESG concerns about this = document.  The
IESG expects that these issues will be addressed = when future versions
of HIP are designed.

In case of complex = Security Policy Databases (SPDs) and the co-
existence of HIP and = security-related protocols such as IKE,
implementors may encounter = conditions that are unspecified in these
documents.  For = example, when the SPD defines an IP address subnet to
be protected = and a HIP host is residing in that IP address area,
there is a = possibility that the communication is encrypted multiple
times. =  Readers are advised to pay special attention when running = HIP
with complex SPD settings.  Future specifications should = clearly
define when multiple encryption is intended, and when it = should be
avoided.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jokela-hip-rfc5202-bis-01= .txt

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

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of = the
Internet-Draft.
<M= ail Attachment>
_______________________________________________
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

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

= --Apple-Mail-8-5157338-- From ari.keranen@nomadiclab.com Tue Jul 13 07:21:21 2010 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 36CAC3A6890 for ; Tue, 13 Jul 2010 07:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 stgtaFAaFHrG for ; Tue, 13 Jul 2010 07:21:20 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 04F633A67E7 for ; Tue, 13 Jul 2010 07:21:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id DADE64E6D5 for ; Tue, 13 Jul 2010 17:21: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 ZK9Ybt+BeKr5 for ; Tue, 13 Jul 2010 17:21:21 +0300 (EEST) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id C53CC4E6D4 for ; Tue, 13 Jul 2010 17:21:21 +0300 (EEST) Message-ID: <4C3C7661.4000408@nomadiclab.com> Date: Tue, 13 Jul 2010 17:21:21 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Updating parameter type values for VIA and BONE drafts 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, 13 Jul 2010 14:21:21 -0000 Hi all, As discussed in the other thread, instead of adding new parameters to the 0-1023 range, we should rather use higher ranges for "non-essential" type of extensions. Currently the text in RFC5201 about the ranges says: Parameters numbered between 0-1023 are used in HIP handshake and update procedures and are covered by signatures. Parameters numbered between 1024-2047 are reserved. Parameters numbered between 2048-4095 are used for parameters related to HIP transform types. Parameters numbered between 4096 and (2^16 - 2^12) 61439 are reserved. The VIA and BONE extensions are not actually "handshake and update procedures", or "essential stuff", but we originally put the signed parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other possible ranges, according to the text above, were "reserved". However, better approach would be to use a higher range for this kind of extensions. For example, 4096-16383. Latest version of HICCUPS [3] already uses that range and we were planning to move the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and 4600, respectively), unless someone objects. Cheers, Ari [1] http://tools.ietf.org/html/draft-ietf-hip-bone-07#section-6.1 [2] http://tools.ietf.org/html/draft-ietf-hip-via-03#section-4.1 [3] http://tools.ietf.org/html/draft-ietf-hip-hiccups-05#section-4.1 From heer@informatik.rwth-aachen.de Wed Jul 14 03:03:42 2010 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 678183A659C for ; Wed, 14 Jul 2010 03:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 ZZUC50BdDgHp for ; Wed, 14 Jul 2010 03:03:38 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id CDDE93A6952 for ; Wed, 14 Jul 2010 03:03:37 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L5J00KVWLAATZ90@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 14 Jul 2010 12:03:46 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,201,1278280800"; d="scan'208";a="65162313" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 14 Jul 2010 12:03:46 +0200 Received: from umic-i4-137-226-45-90.nn.rwth-aachen.de ([unknown] [137.226.45.90]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L5J00CKTLAAX180@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 14 Jul 2010 12:03:46 +0200 (CEST) From: Tobias Heer In-reply-to: <4C3C7661.4000408@nomadiclab.com> Date: Wed, 14 Jul 2010 12:03:57 +0200 Message-id: <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de> References: <4C3C7661.4000408@nomadiclab.com> To: HIP WG X-Mailer: Apple Mail (2.1081) Subject: Re: [Hipsec] Updating parameter type values for VIA and BONE drafts 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, 14 Jul 2010 10:03:42 -0000 Hello Ari, Am 13.07.2010 um 16:21 schrieb Ari Keranen: > Hi all, > > As discussed in the other thread, instead of adding new parameters to the 0-1023 range, we should rather use higher ranges for "non-essential" type of extensions. Currently the text in RFC5201 about the ranges says: > > Parameters numbered between 0-1023 are used in HIP > handshake and update procedures and are covered by signatures. > Parameters numbered between 1024-2047 are reserved. Parameters > numbered between 2048-4095 are used for parameters related to HIP > transform types. Parameters numbered between 4096 and (2^16 - 2^12) > 61439 are reserved. > > The VIA and BONE extensions are not actually "handshake and update procedures", or "essential stuff", but we originally put the signed parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other possible ranges, according to the text above, were "reserved". > > However, better approach would be to use a higher range for this kind of extensions. For example, 4096-16383. Latest version of HICCUPS [3] already uses that range and we were planning to move the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and 4600, respectively), unless someone objects. I agree that the current assignments are way to coarse grained. However, I am not really convinced that putting all extensions into one big bucket is the solution we want. Right now we have a grouping based on functionality and security requirements (signed/unsigned, BEX, other stuff). I like that approach (and would like it even better if it was a bit more fine grained) because it allows implementors to classify parameters easily. Putting every extension into the same range would mean that you can only distinguish between extension and non-extension. I would rather try to come up with a sensible allocation based on functions (although I don't have one at hand right now). Maybe this could be one agenda item for the 5201-bis document crafting session? BR, Tobias > > > Cheers, > Ari > > [1] http://tools.ietf.org/html/draft-ietf-hip-bone-07#section-6.1 > [2] http://tools.ietf.org/html/draft-ietf-hip-via-03#section-4.1 > [3] http://tools.ietf.org/html/draft-ietf-hip-hiccups-05#section-4.1 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From ari.keranen@nomadiclab.com Wed Jul 14 03:22:53 2010 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 ABC203A677C for ; Wed, 14 Jul 2010 03:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 6E5uca-bGuGy for ; Wed, 14 Jul 2010 03:22:52 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 438C33A69C0 for ; Wed, 14 Jul 2010 03:22:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id D00AB4E6DA; Wed, 14 Jul 2010 13:23:00 +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 FigYM828Pemj; Wed, 14 Jul 2010 13:23:00 +0300 (EEST) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 460294E6D5; Wed, 14 Jul 2010 13:23:00 +0300 (EEST) Message-ID: <4C3D8FFF.9020005@nomadiclab.com> Date: Wed, 14 Jul 2010 13:22:55 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Tobias Heer References: <4C3C7661.4000408@nomadiclab.com> <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de> In-Reply-To: <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] Updating parameter type values for VIA and BONE drafts 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, 14 Jul 2010 10:22:54 -0000 Hi Tobias, On 07/14/2010 01:03 PM, Tobias Heer wrote: > Hello Ari, > > Am 13.07.2010 um 16:21 schrieb Ari Keranen: > >> Hi all, >> >> As discussed in the other thread, instead of adding new parameters >> to the 0-1023 range, we should rather use higher ranges for >> "non-essential" type of extensions. Currently the text in RFC5201 >> about the ranges says: >> >> Parameters numbered between 0-1023 are used in HIP handshake and >> update procedures and are covered by signatures. Parameters >> numbered between 1024-2047 are reserved. Parameters numbered >> between 2048-4095 are used for parameters related to HIP transform >> types. Parameters numbered between 4096 and (2^16 - 2^12) 61439 >> are reserved. >> >> The VIA and BONE extensions are not actually "handshake and update >> procedures", or "essential stuff", but we originally put the signed >> parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other >> possible ranges, according to the text above, were "reserved". >> >> However, better approach would be to use a higher range for this >> kind of extensions. For example, 4096-16383. Latest version of >> HICCUPS [3] already uses that range and we were planning to move >> the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and >> 4600, respectively), unless someone objects. > > I agree that the current assignments are way to coarse grained. > However, I am not really convinced that putting all extensions into > one big bucket is the solution we want. Right now we have a grouping > based on functionality and security requirements (signed/unsigned, > BEX, other stuff). I like that approach (and would like it even > better if it was a bit more fine grained) because it allows > implementors to classify parameters easily. Putting every extension > into the same range would mean that you can only distinguish between > extension and non-extension. I would rather try to come up with a > sensible allocation based on functions (although I don't have one at > hand right now). Actually, I did not mean to change the current "signed/unsigned, BEX, other stuff" grouping but rather add more semantics to the "other stuff" parts (signed and unsigned). Anyhow, I guess we agree that the 0-1023 is not the best range for these new parameters. I think the 4096+ range is good since that will leave us some space between the "BEX range" and the "new range" if need for a more "BEXy" range shows up later. Right now that range is listed by IANA as "first come first served" so we don't need any real process for this, but I'm just asking if anyone thinks this is a bad idea. > Maybe this could be one agenda item for the 5201-bis document > crafting session? That would make sense. Cheers, Ari >> [1] http://tools.ietf.org/html/draft-ietf-hip-bone-07#section-6.1 >> [2] http://tools.ietf.org/html/draft-ietf-hip-via-03#section-4.1 >> [3] >> http://tools.ietf.org/html/draft-ietf-hip-hiccups-05#section-4.1 From rgm@htt-consult.com Wed Jul 14 06:22:42 2010 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 7610E3A681C for ; Wed, 14 Jul 2010 06:22:42 -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=[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 H-apcivKjy51 for ; Wed, 14 Jul 2010 06:22:41 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 5FE253A6877 for ; Wed, 14 Jul 2010 06:22:40 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id D0F0D68B0E; Wed, 14 Jul 2010 13:14:16 +0000 (UTC) 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 gyuyRqj9XJMb; Wed, 14 Jul 2010 09:14:07 -0400 (EDT) Received: from nc2400.htt-consult.com (unknown [12.2.200.10]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id ACD9A68B4F; Wed, 14 Jul 2010 09:14:06 -0400 (EDT) Message-ID: <4C3DBA1B.7060308@htt-consult.com> Date: Wed, 14 Jul 2010 06:22:35 -0700 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tobias Heer References: <4C3C7661.4000408@nomadiclab.com> <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de> In-Reply-To: <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] Updating parameter type values for VIA and BONE drafts 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, 14 Jul 2010 13:22:42 -0000 On 07/14/2010 03:03 AM, Tobias Heer wrote: > Hello Ari, > > Am 13.07.2010 um 16:21 schrieb Ari Keranen: > > >> Hi all, >> >> As discussed in the other thread, instead of adding new parameters to the 0-1023 range, we should rather use higher ranges for "non-essential" type of extensions. Currently the text in RFC5201 about the ranges says: >> >> Parameters numbered between 0-1023 are used in HIP >> handshake and update procedures and are covered by signatures. >> Parameters numbered between 1024-2047 are reserved. Parameters >> numbered between 2048-4095 are used for parameters related to HIP >> transform types. Parameters numbered between 4096 and (2^16 - 2^12) >> 61439 are reserved. >> >> The VIA and BONE extensions are not actually "handshake and update procedures", or "essential stuff", but we originally put the signed parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other possible ranges, according to the text above, were "reserved". >> >> However, better approach would be to use a higher range for this kind of extensions. For example, 4096-16383. Latest version of HICCUPS [3] already uses that range and we were planning to move the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and 4600, respectively), unless someone objects. >> > I agree that the current assignments are way to coarse grained. However, I am not really convinced that putting all extensions into one big bucket is the solution we want. Right now we have a grouping based on functionality and security requirements (signed/unsigned, BEX, other stuff). I like that approach (and would like it even better if it was a bit more fine grained) because it allows implementors to classify parameters easily. Putting every extension into the same range would mean that you can only distinguish between extension and non-extension. I would rather try to come up with a sensible allocation based on functions (although I don't have one at hand right now). > > Maybe this could be one agenda item for the 5201-bis document crafting session? In HIP DEX I have a HIP_MAC_3 parameter since its MACing rules are different than HIP_MAC or HIP_MAC_2. So do I use the type +1 of HIP_MAC_2 or some other range? I need an ENCRYPTED parameter but it has a much different content than what HIP BEX is encrypting. Do I use the same parameter or make a different one? In HIP DEX R1, I2, R2, UPDATE, NOTIFY, and CLOSE have different constructions. R1, I2, R2 should not be a problem using the same Packet Type, by the HIP_SUITE_ID you know you are doing HPI DEX. But what about UPDATE, NOTIFY, and CLOSE? Is the HIP_SUITE_ID enough information to process them appropriately? (note that the difference is they lack a HIP_SIGNATURE parameter, as DEX cannot do a signing operation). Then there is the HIP RFID ID. How should the parameters there be numbered and what about the Packet Types? As I look at the evolving HIP Exchange 'family', I see we are able to target different classes of computing entities. This is goodness and I am looking forward to pushing this concept in a number of venues. HIP BEX - For REAL computing platforms, PCs, PDA, Network Infrastructure things HIP DEX - For constrained sensors and embedded processors HIP TEX - (what I am calling the RFID exchange, I don't like REX, it is for any tag object) I am thinking of reworking a part of 4423-bis to discuss a family of exchanges beyond just the Base EXchange. From heer@informatik.rwth-aachen.de Wed Jul 14 07:18:47 2010 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 6672F3A6950 for ; Wed, 14 Jul 2010 07:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 scnZ5fJYbEb0 for ; Wed, 14 Jul 2010 07:18:45 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 5207A3A68DB for ; Wed, 14 Jul 2010 07:18:45 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L5J00G5CX3I5HH0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 14 Jul 2010 16:18:54 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,202,1278280800"; d="scan'208";a="34683487" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 14 Jul 2010 16:18:54 +0200 Received: from [137.226.12.157] ([unknown] [137.226.12.157]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L5J00GFJX3I3K30@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 14 Jul 2010 16:18:54 +0200 (CEST) From: Tobias Heer In-reply-to: <4C3DBA1B.7060308@htt-consult.com> Date: Wed, 14 Jul 2010 16:19:05 +0200 Message-id: <82291E08-91E0-4913-937B-2C7B578481DC@cs.rwth-aachen.de> References: <4C3C7661.4000408@nomadiclab.com> <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de> <4C3DBA1B.7060308@htt-consult.com> To: HIP WG X-Mailer: Apple Mail (2.1081) Subject: [Hipsec] DEX parameters and parameter usage (was: Updating parameter type values for VIA and BONE drafts) 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, 14 Jul 2010 14:18:47 -0000 Hello Robert, Am 14.07.2010 um 15:22 schrieb Robert Moskowitz: > On 07/14/2010 03:03 AM, Tobias Heer wrote: >> Hello Ari, >> >> Am 13.07.2010 um 16:21 schrieb Ari Keranen: >> >> >>> Hi all, >>> >>> As discussed in the other thread, instead of adding new parameters to the 0-1023 range, we should rather use higher ranges for "non-essential" type of extensions. Currently the text in RFC5201 about the ranges says: >>> >>> Parameters numbered between 0-1023 are used in HIP >>> handshake and update procedures and are covered by signatures. >>> Parameters numbered between 1024-2047 are reserved. Parameters >>> numbered between 2048-4095 are used for parameters related to HIP >>> transform types. Parameters numbered between 4096 and (2^16 - 2^12) >>> 61439 are reserved. >>> >>> The VIA and BONE extensions are not actually "handshake and update procedures", or "essential stuff", but we originally put the signed parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other possible ranges, according to the text above, were "reserved". >>> >>> However, better approach would be to use a higher range for this kind of extensions. For example, 4096-16383. Latest version of HICCUPS [3] already uses that range and we were planning to move the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and 4600, respectively), unless someone objects. >>> >> I agree that the current assignments are way to coarse grained. However, I am not really convinced that putting all extensions into one big bucket is the solution we want. Right now we have a grouping based on functionality and security requirements (signed/unsigned, BEX, other stuff). I like that approach (and would like it even better if it was a bit more fine grained) because it allows implementors to classify parameters easily. Putting every extension into the same range would mean that you can only distinguish between extension and non-extension. I would rather try to come up with a sensible allocation based on functions (although I don't have one at hand right now). >> >> Maybe this could be one agenda item for the 5201-bis document crafting session? > > In HIP DEX I have a HIP_MAC_3 parameter since its MACing rules are different than HIP_MAC or HIP_MAC_2. So do I use the type +1 of HIP_MAC_2 or some other range? +1 implies that the HIP_MAC_3 is not critical. Is this the case? Otherwise, +2 would be appropriate. Some spacing might not hurt either. > > I need an ENCRYPTED parameter but it has a much different content than what HIP BEX is encrypting. Do I use the same parameter or make a different one? I would suggest to use a different one if it does something different. > > In HIP DEX R1, I2, R2, UPDATE, NOTIFY, and CLOSE have different constructions. R1, I2, R2 should not be a problem using the same Packet Type, by the HIP_SUITE_ID you know you are doing HPI DEX. But what about UPDATE, NOTIFY, and CLOSE? Is the HIP_SUITE_ID enough information to process them appropriately? (note that the difference is they lack a HIP_SIGNATURE parameter, as DEX cannot do a signing operation). > I believe the packet types should stay the same as long as the function is identical. They may have different parameters but no implementation will ever run into the problem of having to handle a Diet HIP CLOSE, UPDATE or NOTIFY if it does not complete a DEX first. Of course it could receive such packet as result of an error but that would just be a malformed packet then, right? > Then there is the HIP RFID ID. How should the parameters there be numbered and what about the Packet Types? It is difficult to answer this question without knowing the actual differences between HIP BEX and the RFID thing. > > As I look at the evolving HIP Exchange 'family', I see we are able to target different classes of computing entities. This is goodness and I am looking forward to pushing this concept in a number of venues. > > HIP BEX - For REAL computing platforms, PCs, PDA, Network Infrastructure things > HIP DEX - For constrained sensors and embedded processors > HIP TEX - (what I am calling the RFID exchange, I don't like REX, it is for any tag object) > > I am thinking of reworking a part of 4423-bis to discuss a family of exchanges beyond just the Base EXchange. > I would be cautious not to stretch this too far. It makes sense to be flexible but engineered flexibility often comes at the price of complexity. I think there should be a good amount of overlap between the concepts and technical solutions of BEX, DEX, and TEX to really state that they are all HIP. Tobias > -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From heer@informatik.rwth-aachen.de Wed Jul 14 07:32:24 2010 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 28B213A6B6C for ; Wed, 14 Jul 2010 07:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.151 X-Spam-Level: X-Spam-Status: No, score=-4.151 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 BB9v3Qzp2Or0 for ; Wed, 14 Jul 2010 07:32:20 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id C86FB3A6B95 for ; Wed, 14 Jul 2010 07:24:33 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L5J001NUXD6XDH0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 14 Jul 2010 16:24:42 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,202,1278280800"; d="scan'208";a="65208082" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 14 Jul 2010 16:24:38 +0200 Received: from [137.226.12.157] ([unknown] [137.226.12.157]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L5J00GJDXD23K30@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 14 Jul 2010 16:24:38 +0200 (CEST) From: Tobias Heer In-reply-to: <4C3D8FFF.9020005@nomadiclab.com> Date: Wed, 14 Jul 2010 16:24:50 +0200 Message-id: References: <4C3C7661.4000408@nomadiclab.com> <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de> <4C3D8FFF.9020005@nomadiclab.com> To: Ari Keranen X-Mailer: Apple Mail (2.1081) Cc: HIP WG Subject: [Hipsec] Parameter space design (was: Updating parameter type values for VIA and BONE drafts) 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, 14 Jul 2010 14:32:24 -0000 Hello Ari, Am 14.07.2010 um 12:22 schrieb Ari Keranen: > Hi Tobias, > > On 07/14/2010 01:03 PM, Tobias Heer wrote: >> Hello Ari, >> Am 13.07.2010 um 16:21 schrieb Ari Keranen: >>> Hi all, >>> As discussed in the other thread, instead of adding new parameters >>> to the 0-1023 range, we should rather use higher ranges for >>> "non-essential" type of extensions. Currently the text in RFC5201 >>> about the ranges says: >>> Parameters numbered between 0-1023 are used in HIP handshake and >>> update procedures and are covered by signatures. Parameters >>> numbered between 1024-2047 are reserved. Parameters numbered >>> between 2048-4095 are used for parameters related to HIP transform >>> types. Parameters numbered between 4096 and (2^16 - 2^12) 61439 >>> are reserved. >>> The VIA and BONE extensions are not actually "handshake and update >>> procedures", or "essential stuff", but we originally put the signed >>> parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other >>> possible ranges, according to the text above, were "reserved". >>> However, better approach would be to use a higher range for this >>> kind of extensions. For example, 4096-16383. Latest version of >>> HICCUPS [3] already uses that range and we were planning to move >>> the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and >>> 4600, respectively), unless someone objects. >> I agree that the current assignments are way to coarse grained. >> However, I am not really convinced that putting all extensions into >> one big bucket is the solution we want. Right now we have a grouping >> based on functionality and security requirements (signed/unsigned, >> BEX, other stuff). I like that approach (and would like it even >> better if it was a bit more fine grained) because it allows >> implementors to classify parameters easily. Putting every extension >> into the same range would mean that you can only distinguish between >> extension and non-extension. I would rather try to come up with a >> sensible allocation based on functions (although I don't have one at >> hand right now). > > Actually, I did not mean to change the current "signed/unsigned, BEX, other stuff" grouping but rather add more semantics to the "other stuff" parts (signed and unsigned). > We are absolutely on the same page here. Using the current state as reference you are right. Using a more fine grained approach, which we might have in the near future, large buckets make no sense. Since we don't have that shiny new approach you are right to propose to take this and that number. I just wonder if we can't come up with something better. > Anyhow, I guess we agree that the 0-1023 is not the best range for these new parameters. Absolutely. > I think the 4096+ range is good since that will leave us some space between the "BEX range" and the "new range" if need for a more "BEXy" range shows up later. Considering a possible redesign of the parameter space, I think it is a bit early to decide that. > Right now that range is listed by IANA as "first come first served" so we don't need any real process for this, but I'm just asking if anyone thinks this is a bad idea. > >> Maybe this could be one agenda item for the 5201-bis document >> crafting session? > > That would make sense. > Can we agree to come up with a "good" parameter space segmentation during the next IETF and take further steps then? Otherwise, we can also collect suggestions for a parameter space redesign here on the list. However, it would be nice to always have the big picture in mind and not discuss about subspaces in isolation. Right now it the complete parameter space looks like: 0 - 1023 Handshake 1024 - 2047 Reserved 2048 - 4095 Signed if signature is present 4096 - 61439 Reserved 61440 - 62463 Signatures and signed MACs 62464 - 63487 Parameters that are not signed 63488 - 64511 Rendezvous and relaying 64512 - 65535 Reserved Any suggestions for new groups based on the parameter use? BR, Tobias > > Cheers, > Ari > >>> [1] http://tools.ietf.org/html/draft-ietf-hip-bone-07#section-6.1 [2] http://tools.ietf.org/html/draft-ietf-hip-via-03#section-4.1 [3] >>> http://tools.ietf.org/html/draft-ietf-hip-hiccups-05#section-4.1 > -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From rgm@htt-consult.com Wed Jul 14 08:58:31 2010 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 1F8633A6B78 for ; Wed, 14 Jul 2010 08:58:31 -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=[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 pZvhKH7nAKQY for ; Wed, 14 Jul 2010 08:58:30 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 811AA3A6A33 for ; Wed, 14 Jul 2010 08:58:27 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 83D1068B24; Wed, 14 Jul 2010 15:50:02 +0000 (UTC) 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 BT8obndHwDBJ; Wed, 14 Jul 2010 11:49:52 -0400 (EDT) Received: from nc2400.htt-consult.com (unknown [12.2.202.16]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 60A4F68AD0; Wed, 14 Jul 2010 11:49:52 -0400 (EDT) Message-ID: <4C3DDE9E.10508@htt-consult.com> Date: Wed, 14 Jul 2010 08:58:22 -0700 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tobias Heer References: <4C3C7661.4000408@nomadiclab.com> <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de> <4C3DBA1B.7060308@htt-consult.com> <82291E08-91E0-4913-937B-2C7B578481DC@cs.rwth-aachen.de> In-Reply-To: <82291E08-91E0-4913-937B-2C7B578481DC@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] DEX parameters and parameter usage 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, 14 Jul 2010 15:58:31 -0000 > > Hello Robert, > > Am 14.07.2010 um 15:22 schrieb Robert Moskowitz: > > >> On 07/14/2010 03:03 AM, Tobias Heer wrote: >> >>> Hello Ari, >>> >>> Am 13.07.2010 um 16:21 schrieb Ari Keranen: >>> >>> >>> >>>> Hi all, >>>> >>>> As discussed in the other thread, instead of adding new parameters to the 0-1023 range, we should rather use higher ranges for "non-essential" type of extensions. Currently the text in RFC5201 about the ranges says: >>>> >>>> Parameters numbered between 0-1023 are used in HIP >>>> handshake and update procedures and are covered by signatures. >>>> Parameters numbered between 1024-2047 are reserved. Parameters >>>> numbered between 2048-4095 are used for parameters related to HIP >>>> transform types. Parameters numbered between 4096 and (2^16 - 2^12) >>>> 61439 are reserved. >>>> >>>> The VIA and BONE extensions are not actually "handshake and update procedures", or "essential stuff", but we originally put the signed parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other possible ranges, according to the text above, were "reserved". >>>> >>>> However, better approach would be to use a higher range for this kind of extensions. For example, 4096-16383. Latest version of HICCUPS [3] already uses that range and we were planning to move the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and 4600, respectively), unless someone objects. >>>> >>>> >>> I agree that the current assignments are way to coarse grained. However, I am not really convinced that putting all extensions into one big bucket is the solution we want. Right now we have a grouping based on functionality and security requirements (signed/unsigned, BEX, other stuff). I like that approach (and would like it even better if it was a bit more fine grained) because it allows implementors to classify parameters easily. Putting every extension into the same range would mean that you can only distinguish between extension and non-extension. I would rather try to come up with a sensible allocation based on functions (although I don't have one at hand right now). >>> >>> Maybe this could be one agenda item for the 5201-bis document crafting session? >>> >> In HIP DEX I have a HIP_MAC_3 parameter since its MACing rules are different than HIP_MAC or HIP_MAC_2. So do I use the type +1 of HIP_MAC_2 or some other range? >> > +1 implies that the HIP_MAC_3 is not critical. Is this the case? Otherwise, +2 would be appropriate. Some spacing might not hurt either. > > >> I need an ENCRYPTED parameter but it has a much different content than what HIP BEX is encrypting. Do I use the same parameter or make a different one? >> > I would suggest to use a different one if it does something different. > >> In HIP DEX R1, I2, R2, UPDATE, NOTIFY, and CLOSE have different constructions. R1, I2, R2 should not be a problem using the same Packet Type, by the HIP_SUITE_ID you know you are doing HPI DEX. But what about UPDATE, NOTIFY, and CLOSE? Is the HIP_SUITE_ID enough information to process them appropriately? (note that the difference is they lack a HIP_SIGNATURE parameter, as DEX cannot do a signing operation). >> >> > I believe the packet types should stay the same as long as the function is identical. They may have different parameters but no implementation will ever run into the problem of having to handle a Diet HIP CLOSE, UPDATE or NOTIFY if it does not complete a DEX first. Of course it could receive such packet as result of an error but that would just be a malformed packet then, right? > > > >> Then there is the HIP RFID ID. How should the parameters there be numbered and what about the Packet Types? >> > It is difficult to answer this question without knowing the actual differences between HIP BEX and the RFID thing. > draft-irtf-hiprg-rfid-00.txt > >> As I look at the evolving HIP Exchange 'family', I see we are able to target different classes of computing entities. This is goodness and I am looking forward to pushing this concept in a number of venues. >> >> HIP BEX - For REAL computing platforms, PCs, PDA, Network Infrastructure things >> HIP DEX - For constrained sensors and embedded processors >> HIP TEX - (what I am calling the RFID exchange, I don't like REX, it is for any tag object) >> >> I am thinking of reworking a part of 4423-bis to discuss a family of exchanges beyond just the Base EXchange. >> >> > I would be cautious not to stretch this too far. It makes sense to be flexible but engineered flexibility often comes at the price of complexity. I think there should be a good amount of overlap between the concepts and technical solutions of BEX, DEX, and TEX to really state that they are all HIP. > > Tobias > > >> > > > > From ari.keranen@nomadiclab.com Thu Jul 15 05:51:55 2010 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 C601A3A685F for ; Thu, 15 Jul 2010 05:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 vdUdHd+b1EZo for ; Thu, 15 Jul 2010 05:51:54 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 8870A3A687C for ; Thu, 15 Jul 2010 05:51:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 8E93A4E6CF; Thu, 15 Jul 2010 15:52:01 +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 U3Z8dJYbPv71; Thu, 15 Jul 2010 15:52:01 +0300 (EEST) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 004D94E6BF; Thu, 15 Jul 2010 15:52:00 +0300 (EEST) Message-ID: <4C3F0470.7060009@nomadiclab.com> Date: Thu, 15 Jul 2010 15:52:00 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Tobias Heer References: <4C3C7661.4000408@nomadiclab.com> <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de> <4C3D8FFF.9020005@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] Parameter space design 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, 15 Jul 2010 12:51:55 -0000 On 07/14/2010 05:24 PM, Tobias Heer wrote: > Am 14.07.2010 um 12:22 schrieb Ari Keranen: >> On 07/14/2010 01:03 PM, Tobias Heer wrote: >>> Hello Ari, >>> Am 13.07.2010 um 16:21 schrieb Ari Keranen: >>>> Hi all, >>>> As discussed in the other thread, instead of adding new parameters >>>> to the 0-1023 range, we should rather use higher ranges for >>>> "non-essential" type of extensions. Currently the text in RFC5201 >>>> about the ranges says: >>>> Parameters numbered between 0-1023 are used in HIP handshake and >>>> update procedures and are covered by signatures. Parameters >>>> numbered between 1024-2047 are reserved. Parameters numbered >>>> between 2048-4095 are used for parameters related to HIP transform >>>> types. Parameters numbered between 4096 and (2^16 - 2^12) 61439 >>>> are reserved. >>>> The VIA and BONE extensions are not actually "handshake and update >>>> procedures", or "essential stuff", but we originally put the signed >>>> parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other >>>> possible ranges, according to the text above, were "reserved". >>>> However, better approach would be to use a higher range for this >>>> kind of extensions. For example, 4096-16383. Latest version of >>>> HICCUPS [3] already uses that range and we were planning to move >>>> the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and >>>> 4600, respectively), unless someone objects. >>> I agree that the current assignments are way to coarse grained. >>> However, I am not really convinced that putting all extensions into >>> one big bucket is the solution we want. Right now we have a grouping >>> based on functionality and security requirements (signed/unsigned, >>> BEX, other stuff). I like that approach (and would like it even >>> better if it was a bit more fine grained) because it allows >>> implementors to classify parameters easily. Putting every extension >>> into the same range would mean that you can only distinguish between >>> extension and non-extension. I would rather try to come up with a >>> sensible allocation based on functions (although I don't have one at >>> hand right now). >> Actually, I did not mean to change the current "signed/unsigned, BEX, other stuff" grouping but rather add more semantics to the "other stuff" parts (signed and unsigned). >> > We are absolutely on the same page here. Using the current state as reference you are right. Using a more fine grained approach, which we might have in the near future, large buckets make no sense. Since we don't have that shiny new approach you are right to propose to take this and that number. I just wonder if we can't come up with something better. Maybe we can, but on the other hand, we should try to avoid over engineering this. >> Anyhow, I guess we agree that the 0-1023 is not the best range for these new parameters. > Absolutely. > >> I think the 4096+ range is good since that will leave us some space between the "BEX range" and the "new range" if need for a more "BEXy" range shows up later. > Considering a possible redesign of the parameter space, I think it is a bit early to decide that. > >> Right now that range is listed by IANA as "first come first served" so we don't need any real process for this, but I'm just asking if anyone thinks this is a bad idea. >> >>> Maybe this could be one agenda item for the 5201-bis document >>> crafting session? >> That would make sense. >> > Can we agree to come up with a "good" parameter space segmentation during the next IETF and take further steps then? Otherwise, we can also collect suggestions for a parameter space redesign here on the list. However, it would be nice to always have the big picture in mind and not discuss about subspaces in isolation. I think we should do both; first get some ideas here on the list and then discuss at the meeting -- unless we can come up with good solution before that. Anyway, I would not consider this a critical issue, so we should not spend too much time on this. > Right now it the complete parameter space looks like: > > 0 - 1023 Handshake > 1024 - 2047 Reserved > 2048 - 4095 Signed if signature is present > 4096 - 61439 Reserved > 61440 - 62463 Signatures and signed MACs > 62464 - 63487 Parameters that are not signed > 63488 - 64511 Rendezvous and relaying > 64512 - 65535 Reserved > > Any suggestions for new groups based on the parameter use? I would prefer to keep the "group" definitions high level, and maybe even non-normative. The parameters discussed before are all "overlay networks related" so that could possibly be one group, but I'm not sure if even that is too low-level. Also, I wonder if we would ever have over 1k different "signatures and signed MACs". Cheers, Ari From rgm@htt-consult.com Thu Jul 15 08:17:22 2010 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 F13F93A6A2D for ; Thu, 15 Jul 2010 08:17:21 -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=[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 PL1or9ayc9Vh for ; Thu, 15 Jul 2010 08:17:21 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id BE8BE3A6899 for ; Thu, 15 Jul 2010 08:17:21 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 1709F68A8B; Thu, 15 Jul 2010 15:08:49 +0000 (UTC) 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 Mum5bdGi5iQJ; Thu, 15 Jul 2010 11:08:38 -0400 (EDT) Received: from nc2400.htt-consult.com (unknown [12.2.202.16]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 5CA3B68B43; Thu, 15 Jul 2010 11:08:37 -0400 (EDT) Message-ID: <4C3F2676.6080603@htt-consult.com> Date: Thu, 15 Jul 2010 08:17:10 -0700 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tobias Heer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG , hiprg@irtf.org Subject: Re: [Hipsec] Document crafting meeting RFC5201-bis 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, 15 Jul 2010 15:17:22 -0000 On 06/29/2010 02:49 AM, Tobias Heer wrote: > Hi everyone, > > as discussed on the list, we would like to have a document discussion and crafting meeting for RFC5201-bis during the IETF in Maastricht. > > The goal of this crafting session is to discuss the specific changes in detail and to identify areas that need further work. I would be happy to welcome as many of you as possible. > I set up a doodle link in order to find a suitable time slot. Please mark as many slots as possible to make it easy/suitable to find a slot that works for most of you. > > http://www.doodle.com/gbsrevygvm968ddz > > Please indicate your preferences until July, 10th, so that we can fix a place and make the necessary arrangements. > It is past July 10, but only Tobias and I entered any schedule time. I just updated my time. It would be nice if others would plan on joining us and contribute. > Keep in mind that the HIP RG is scheduled for: Tu 9:00-11:30 > > A new version of 5201-bis and the corresponding changelog will be available soon. > > BR, > > Tobias > > > > From heer@informatik.rwth-aachen.de Thu Jul 15 08:20:52 2010 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 270B93A6890 for ; Thu, 15 Jul 2010 08:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.476 X-Spam-Level: X-Spam-Status: No, score=-4.476 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 44tzuSMq1Q30 for ; Thu, 15 Jul 2010 08:20:47 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 47A853A67C2 for ; Thu, 15 Jul 2010 08:20:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L5L001BAUMW6130@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 15 Jul 2010 17:20:56 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,209,1278280800"; d="scan'208";a="65378064" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 15 Jul 2010 17:20:55 +0200 Received: from umic-i4-137-226-45-90.nn.rwth-aachen.de ([unknown] [137.226.45.90]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L5L0009RUMW8A30@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 15 Jul 2010 17:20:56 +0200 (CEST) From: Tobias Heer Date: Thu, 15 Jul 2010 17:21:08 +0200 Message-id: <6F0219A5-E5F4-41EE-A910-78687DED3437@cs.rwth-aachen.de> To: HIP WG , hiprg@irtf.org X-Mailer: Apple Mail (2.1081) Subject: [Hipsec] RFC5201-bis meeting 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, 15 Jul 2010 15:20:52 -0000 Hi everyone, I would like to remind you of the document discussion and crafting meeting for RFC5201-bis during the IETF in Maastricht. Please indicate your preferred meeting time via the following link: http://www.doodle.com/gbsrevygvm968ddz The goal of this crafting session is to discuss the specific changes in detail and to identify areas that need further work. I would be happy to welcome as many of you as possible. Please keep in mind that the HIP RG is scheduled for: Tu 9:00-11:30 BR, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From root@core3.amsl.com Mon Jul 12 14:30:24 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1E4673A6A2F; Mon, 12 Jul 2010 14:30:19 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100712213023.1E4673A6A2F@core3.amsl.com> Date: Mon, 12 Jul 2010 14:30:19 -0700 (PDT) X-Mailman-Approved-At: Thu, 22 Jul 2010 00:06:30 -0700 Cc: hipsec@ietf.org, gonzalo.camarillo@ericsson.com Subject: [Hipsec] WG Review: Recharter of Host Identity Protocol (hip) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org 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, 12 Jul 2010 21:30:24 -0000 A modified charter has been submitted for the Host Identity Protocol (hip) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Monday, July 19, 2010. Host Identity Protocol (hip) -------------------- Current Status: Active Working Group Last Modified: 2010-07-12 Personnel Chairs: David Ward Gonzalo Camarillo Area Director: Ralph Droms Mailing List Address: hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/ Jabber Chat Room Address: xmpp:hip@jabber.ietf.org Logs: http://jabber.ietf.org/logs/hip/ Description of Working Group The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys, from which end-point identifiers are taken. The public keys are typically, but not necessarily, self generated. HIP uses existing IP addressing and forwarding for locators and packet delivery. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. The HIP WG was chartered to publish protocol specifications in documents whose quality and security properties would meet the requirements for publication as standards track documents. These specifications have been published as Experimental RFCs, because the effects of the protocol on applications and on the Internet as a whole were unknown. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. The IRTF HIP RG will publish a document with results from the HIP experiment. The results to be published will justify publication of the HIP protocols in standards track documents. This WG will produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. In parallel with this working group, the IRTF HIP RG mentioned above has a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 as standards track RFCs. o Specify in a standards track RFC how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. Goals and Milestones Done Submit Native API specification to the IESG Done Submit Framework for HIP overlays specification to the IESG Done Submit Multi-hop routing mechanism for HIP Done Submit Upper-layer data transport in HIP to the IESG Sep 2010 WGLC Certs in HIP base exchange specification Sep 2010 WGLC RFC4423bis Sep 2010 WGLC RFC4843bis Sep 2010 WGLC RFC5201bis Sep 2010 WGLC RFC5202bis Oct 2010 Submit Certs in HIP base exchange specification to the IESG Oct 2010 Submit RFC4423bis to the IESG Oct 2010 Submit RFC4843bis to the IESG Oct 2010 Submit RFC5201bis to the IESG Oct 2010 Submit RFC5202bis to the IESG Dec 2010 WGLC RFC5203bis Dec 2010 WGLC RFC5204bis Dec 2010 WGLC RFC5205bis Dec 2010 WGLC the mobility portion of RFC5206bis Jan 2011 Submit RFC5203bis to the IESG Jan 2011 Submit RFC5204bis to the IESG Jan 2011 Submit RFC5205bis to the IESG Jan 2011 Submit the mobility portion of RFC5206bis to the IESG Feb 2011 WGLC RFC5770bis Feb 2011 WGLC the multihoming portion of RFC5206bis Mar 2011 Submit RFC5770bis to the IESG Mar 2011 Submit the multihoming portion of RFC5206bis to the IESG Apr 2011 Recharter or close the WG From wwwrun@core3.amsl.com Mon Jul 19 09:12:54 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 589C33A6969; Mon, 19 Jul 2010 09:12:53 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100719161254.589C33A6969@core3.amsl.com> Date: Mon, 19 Jul 2010 09:12:54 -0700 (PDT) X-Mailman-Approved-At: Thu, 22 Jul 2010 00:06:30 -0700 Cc: hip mailing list , Internet Architecture Board , hip chair , RFC Editor Subject: [Hipsec] Document Action: 'HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment' 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: Mon, 19 Jul 2010 16:12:54 -0000 The IESG has approved the following document: - 'HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment ' 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-bone-07.txt Technical Summary This document specifies a framework to build HIP (Host Identity Protocol)-based overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as peer protocols. Working Group Summary There was strong consensus on this document. Document Quality There are prototype implementations of this spec. A few vendors have expressed interest in implementing this in the context of P2PSIP services. Personnel David Ward is the document shepherd for this document. Ralph Droms is the responsible AD for this document.Working Group Summary From wwwrun@core3.amsl.com Mon Jul 19 09:14:12 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B631E3A6B35; Mon, 19 Jul 2010 09:14:12 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100719161412.B631E3A6B35@core3.amsl.com> Date: Mon, 19 Jul 2010 09:14:12 -0700 (PDT) X-Mailman-Approved-At: Thu, 22 Jul 2010 00:06:30 -0700 Cc: hip mailing list , Internet Architecture Board , hip chair , RFC Editor Subject: [Hipsec] Document Action: 'Host Identity Protocol (HIP) Multi-hop Routing Extension' 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: Mon, 19 Jul 2010 16:14:12 -0000 The IESG has approved the following document: - 'Host Identity Protocol (HIP) Multi-hop Routing Extension ' 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-via-03.txt Technical Summary This document specifies two extensions to HIP to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a host sending a HIP packet can define a set of hosts that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of hosts that forwarded it. Working Group Summary There was strong consensus on this document. Document Quality There are prototype implementations of this spec. A few vendors have expressed interest in implementing this in the context of HIP BONE overlays. Personnel David Ward is the document shepherd for this document. Ralph Droms is the responsible AD for this document. From rgm@htt-consult.com Thu Jul 22 01:58:57 2010 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 A86FD3A6A10; Thu, 22 Jul 2010 01:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_FWDLOOK=1.666] 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 rp7O1zvw429h; Thu, 22 Jul 2010 01:58:56 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 551C93A69EB; Thu, 22 Jul 2010 01:58:55 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id A4B0D68B40; Thu, 22 Jul 2010 08:50:19 +0000 (UTC) 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 TeHdZWDFiwuv; Thu, 22 Jul 2010 04:50:09 -0400 (EDT) Received: from nc2400.htt-consult.com (34-185.mops.RWTH-Aachen.DE [134.61.34.185]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 26D3268B26; Thu, 22 Jul 2010 04:50:08 -0400 (EDT) Message-ID: <4C480850.1050100@htt-consult.com> Date: Thu, 22 Jul 2010 10:58:56 +0200 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: iesg@ietf.org References: <20100712213023.1E4673A6A2F@core3.amsl.com> In-Reply-To: <20100712213023.1E4673A6A2F@core3.amsl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, IESG Secretary , gonzalo.camarillo@ericsson.com, ietf-announce@ietf.org Subject: Re: [Hipsec] WG Review: Recharter of Host Identity Protocol (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: Thu, 22 Jul 2010 08:58:57 -0000 Neat. This message was sent out on the 12th, but did not appear until the 22nd... Of course, I am all for it! On 07/12/2010 11:30 PM, IESG Secretary wrote: > A modified charter has been submitted for the Host Identity Protocol (hip) > working group in the Internet Area of the IETF. The IESG has not made any > determination as yet. The modified charter is provided below for > informational purposes only. Please send your comments to the IESG > mailing list (iesg@ietf.org) by Monday, July 19, 2010. > > Host Identity Protocol (hip) > -------------------- > Current Status: Active Working Group > > Last Modified: 2010-07-12 > > Personnel > > Chairs: David Ward > Gonzalo Camarillo > Area Director: Ralph Droms > > Mailing List > Address: hipsec@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec > Archive: http://www.ietf.org/mail-archive/web/hipsec/ > > Jabber Chat > Room Address: xmpp:hip@jabber.ietf.org > Logs: http://jabber.ietf.org/logs/hip/ > > > Description of Working Group > > The Host Identity Protocol (HIP) provides a method of separating the > end-point identifier and locator roles of IP addresses. It introduces > a new Host Identity (HI) name space, based on public keys, from which > end-point identifiers are taken. The public keys are typically, but > not necessarily, self generated. HIP uses existing IP addressing and > forwarding for locators and packet delivery. > > The architecture and protocol details for these mechanisms are > currently specified in the following Experimental RFCs: > > o HIP Architecture (RFC 4423) > o Host Identity Protocol (RFC 5201) > > There are several publicly known interoperating implementations, some > of which are open source. > > The HIP WG was chartered to publish protocol specifications in > documents whose quality and security properties would meet the > requirements for publication as standards track documents. These > specifications have been published as Experimental RFCs, because the > effects of the protocol on applications and on the Internet as a whole > were unknown. > > The Experimental RFCs produced by the HIP WG allowed the community to > experiment with HIP technologies and learn from these experiments. > The IRTF HIP RG will publish a document with results from the HIP > experiment. The results to be published will justify publication of > the HIP protocols in standards track documents. This WG will produce > standards track versions of the main HIP RFCs taking as a base the > existing Experimental RFCs. The WG will also specify certificate > handling in HIP in a standards track RFC. > > Additionally, the WG will finish the WG items it was working on before > starting the standards track work. These WG items relate to how to > build HIP-based overlays and will result in Experimental RFCs. > > In parallel with this working group, the IRTF HIP RG mentioned above > has a broader scope that includes efforts both on developing the more > forward looking aspects of the HIP architecture and on exploring the > effects that HIP may have on the applications and the Internet. > > The following are charter items for the working group: > > o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 > as standards track RFCs. > > o Specify in a standards track RFC how to carry certificates in the > base exchange. This was removed from the base HIP spec so that the > mechanism is specified in a stand-alone spec. > > o Specify in an Experimental RFC how to build a HIP-based overlay > using RELOAD. > > o Specify in an Experimental RFC how to transport HIP messages over > encrypted connections that were established using HIP. > > > Goals and Milestones > > Done Submit Native API specification to the IESG > Done Submit Framework for HIP overlays specification to the IESG > Done Submit Multi-hop routing mechanism for HIP > Done Submit Upper-layer data transport in HIP to the IESG > Sep 2010 WGLC Certs in HIP base exchange specification > Sep 2010 WGLC RFC4423bis > Sep 2010 WGLC RFC4843bis > Sep 2010 WGLC RFC5201bis > Sep 2010 WGLC RFC5202bis > Oct 2010 Submit Certs in HIP base exchange specification to the > IESG > Oct 2010 Submit RFC4423bis to the IESG > Oct 2010 Submit RFC4843bis to the IESG > Oct 2010 Submit RFC5201bis to the IESG > Oct 2010 Submit RFC5202bis to the IESG > Dec 2010 WGLC RFC5203bis > Dec 2010 WGLC RFC5204bis > Dec 2010 WGLC RFC5205bis > Dec 2010 WGLC the mobility portion of RFC5206bis > Jan 2011 Submit RFC5203bis to the IESG > Jan 2011 Submit RFC5204bis to the IESG > Jan 2011 Submit RFC5205bis to the IESG > Jan 2011 Submit the mobility portion of RFC5206bis to the IESG > Feb 2011 WGLC RFC5770bis > Feb 2011 WGLC the multihoming portion of RFC5206bis > Mar 2011 Submit RFC5770bis to the IESG > Mar 2011 Submit the multihoming portion of RFC5206bis to the IESG > Apr 2011 Recharter or close the WG > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > From heer@informatik.rwth-aachen.de Thu Jul 22 02:08:04 2010 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 D59DF3A6802; Thu, 22 Jul 2010 02:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] 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 NsRKlrQTwWHA; Thu, 22 Jul 2010 02:08:02 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 7790C3A69F8; Thu, 22 Jul 2010 02:08:02 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L5Y006XGC1TW0D0@mta-1.ms.rz.RWTH-Aachen.de>; Thu, 22 Jul 2010 11:08:17 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,242,1278280800"; d="scan'208";a="66193470" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 22 Jul 2010 11:08:17 +0200 Received: from umic-i4-137-226-45-90.nn.rwth-aachen.de ([unknown] [137.226.45.90]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L5Y00JQ2C1TLW60@relay-auth-2.ms.rz.rwth-aachen.de>; Thu, 22 Jul 2010 11:08:17 +0200 (CEST) From: Tobias Heer In-reply-to: <4C480850.1050100@htt-consult.com> Date: Thu, 22 Jul 2010 11:08:17 +0200 Message-id: <5C9D841E-19A9-455C-A660-B2BA89F9071B@cs.rwth-aachen.de> References: <20100712213023.1E4673A6A2F@core3.amsl.com> <4C480850.1050100@htt-consult.com> To: HIP WG , iesg@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [Hipsec] WG Review: Recharter of Host Identity Protocol (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: Thu, 22 Jul 2010 09:08:05 -0000 Am 22.07.2010 um 10:58 schrieb Robert Moskowitz: > Neat. This message was sent out on the 12th, but did not appear until the 22nd... > > Of course, I am all for it! > +1 I support it. Tobias > On 07/12/2010 11:30 PM, IESG Secretary wrote: >> A modified charter has been submitted for the Host Identity Protocol (hip) >> working group in the Internet Area of the IETF. The IESG has not made any >> determination as yet. The modified charter is provided below for >> informational purposes only. Please send your comments to the IESG >> mailing list (iesg@ietf.org) by Monday, July 19, 2010. >> >> Host Identity Protocol (hip) >> -------------------- >> Current Status: Active Working Group >> >> Last Modified: 2010-07-12 >> >> Personnel >> >> Chairs: David Ward >> Gonzalo Camarillo >> Area Director: Ralph Droms >> >> Mailing List >> Address: hipsec@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec >> Archive: http://www.ietf.org/mail-archive/web/hipsec/ >> >> Jabber Chat >> Room Address: xmpp:hip@jabber.ietf.org >> Logs: http://jabber.ietf.org/logs/hip/ >> >> >> Description of Working Group >> >> The Host Identity Protocol (HIP) provides a method of separating the >> end-point identifier and locator roles of IP addresses. It introduces >> a new Host Identity (HI) name space, based on public keys, from which >> end-point identifiers are taken. The public keys are typically, but >> not necessarily, self generated. HIP uses existing IP addressing and >> forwarding for locators and packet delivery. >> >> The architecture and protocol details for these mechanisms are >> currently specified in the following Experimental RFCs: >> >> o HIP Architecture (RFC 4423) >> o Host Identity Protocol (RFC 5201) >> >> There are several publicly known interoperating implementations, some >> of which are open source. >> >> The HIP WG was chartered to publish protocol specifications in >> documents whose quality and security properties would meet the >> requirements for publication as standards track documents. These >> specifications have been published as Experimental RFCs, because the >> effects of the protocol on applications and on the Internet as a whole >> were unknown. >> >> The Experimental RFCs produced by the HIP WG allowed the community to >> experiment with HIP technologies and learn from these experiments. >> The IRTF HIP RG will publish a document with results from the HIP >> experiment. The results to be published will justify publication of >> the HIP protocols in standards track documents. This WG will produce >> standards track versions of the main HIP RFCs taking as a base the >> existing Experimental RFCs. The WG will also specify certificate >> handling in HIP in a standards track RFC. >> >> Additionally, the WG will finish the WG items it was working on before >> starting the standards track work. These WG items relate to how to >> build HIP-based overlays and will result in Experimental RFCs. >> >> In parallel with this working group, the IRTF HIP RG mentioned above >> has a broader scope that includes efforts both on developing the more >> forward looking aspects of the HIP architecture and on exploring the >> effects that HIP may have on the applications and the Internet. >> >> The following are charter items for the working group: >> >> o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 >> as standards track RFCs. >> >> o Specify in a standards track RFC how to carry certificates in the >> base exchange. This was removed from the base HIP spec so that the >> mechanism is specified in a stand-alone spec. >> >> o Specify in an Experimental RFC how to build a HIP-based overlay >> using RELOAD. >> >> o Specify in an Experimental RFC how to transport HIP messages over >> encrypted connections that were established using HIP. >> >> >> Goals and Milestones >> >> Done Submit Native API specification to the IESG >> Done Submit Framework for HIP overlays specification to the IESG >> Done Submit Multi-hop routing mechanism for HIP >> Done Submit Upper-layer data transport in HIP to the IESG >> Sep 2010 WGLC Certs in HIP base exchange specification >> Sep 2010 WGLC RFC4423bis >> Sep 2010 WGLC RFC4843bis >> Sep 2010 WGLC RFC5201bis >> Sep 2010 WGLC RFC5202bis >> Oct 2010 Submit Certs in HIP base exchange specification to the >> IESG >> Oct 2010 Submit RFC4423bis to the IESG >> Oct 2010 Submit RFC4843bis to the IESG >> Oct 2010 Submit RFC5201bis to the IESG >> Oct 2010 Submit RFC5202bis to the IESG >> Dec 2010 WGLC RFC5203bis >> Dec 2010 WGLC RFC5204bis >> Dec 2010 WGLC RFC5205bis >> Dec 2010 WGLC the mobility portion of RFC5206bis >> Jan 2011 Submit RFC5203bis to the IESG >> Jan 2011 Submit RFC5204bis to the IESG >> Jan 2011 Submit RFC5205bis to the IESG >> Jan 2011 Submit the mobility portion of RFC5206bis to the IESG >> Feb 2011 WGLC RFC5770bis >> Feb 2011 WGLC the multihoming portion of RFC5206bis >> Mar 2011 Submit RFC5770bis to the IESG >> Mar 2011 Submit the multihoming portion of RFC5206bis to the IESG >> Apr 2011 Recharter or close the WG >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> >> > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From gonzalo.camarillo@ericsson.com Fri Jul 23 03:58:14 2010 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 A38033A6839 for ; Fri, 23 Jul 2010 03:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.863 X-Spam-Level: X-Spam-Status: No, score=-103.863 tagged_above=-999 required=5 tests=[AWL=-1.264, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 pgSFi9viYCgG for ; Fri, 23 Jul 2010 03:58:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 325CF3A6853 for ; Fri, 23 Jul 2010 03:58:12 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-dd-4c4975d679c1 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E3.66.06895.6D5794C4; Fri, 23 Jul 2010 12:58:30 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 12:57:36 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 12:57:36 +0200 Message-ID: <4C4975A0.7020107@ericsson.com> Date: Fri, 23 Jul 2010 13:57:36 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2010 10:57:36.0529 (UTC) FILETIME=[DC35C810:01CB2A55] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Fwd: WG Action: RECHARTER: Host Identity Protocol (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: Fri, 23 Jul 2010 10:58:14 -0000 Hi, as you can see, we have just been rechartered. Now, we have an aggressive time plan ahead of us (look at the milestone dates in the charter). Cheers, Gonzalo -------- Original Message -------- Subject: WG Action: RECHARTER: Host Identity Protocol (hip) Date: Fri, 23 Jul 2010 12:54:36 +0200 From: IESG Secretary To: IETF Announcement list CC: dward@juniper.net , Gonzalo Camarillo , hipsec@ietf.org The Host Identity Protocol (hip) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Host Identity Protocol (hip) --------------------------------------------------- Current Status: Active Working Group Chairs: David Ward Gonzalo Camarillo Internet Area Directors: Jari Arkko Ralph Droms Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/ The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys, from which end-point identifiers are taken. The public keys are typically, but not necessarily, self generated. HIP uses existing IP addressing and forwarding for locators and packet delivery. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. The HIP WG was chartered to publish protocol specifications in documents whose quality and security properties would meet the requirements for publication as standards track documents. These specifications have been published as Experimental RFCs, because the effects of the protocol on applications and on the Internet as a whole were unknown. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. The HIP WG will now produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. The following are charter items for the working group: o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 as standards track RFCs. o Specify in a standards track RFC how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. Goals and Milestones Done Submit Native API specification to the IESG Done Submit Framework for HIP overlays specification to the IESG Done Submit Multi-hop routing mechanism for HIP Done Submit Upper-layer data transport in HIP to the IESG Sep 2010 WGLC Certs in HIP base exchange specification Sep 2010 WGLC RFC4423bis Sep 2010 WGLC RFC4843bis Sep 2010 WGLC RFC5201bis Sep 2010 WGLC RFC5202bis Oct 2010 Submit Certs in HIP base exchange specification to the IESG Oct 2010 Submit RFC4423bis to the IESG Oct 2010 Submit RFC4843bis to the IESG Oct 2010 Submit RFC5201bis to the IESG Oct 2010 Submit RFC5202bis to the IESG Dec 2010 WGLC RFC5203bis Dec 2010 WGLC RFC5204bis Dec 2010 WGLC RFC5205bis Dec 2010 WGLC the mobility portion of RFC5206bis Jan 2011 Submit RFC5203bis to the IESG Jan 2011 Submit RFC5204bis to the IESG Jan 2011 Submit RFC5205bis to the IESG Jan 2011 Submit the mobility portion of RFC5206bis to the IESG Feb 2011 WGLC RFC5770bis Feb 2011 WGLC the multihoming portion of RFC5206bis Mar 2011 Submit RFC5770bis to the IESG Mar 2011 Submit the multihoming portion of RFC5206bis to the IESG Apr 2011 Recharter or close the WG From wwwrun@core3.amsl.com Fri Jul 23 03:54:36 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9694A3A6902; Fri, 23 Jul 2010 03:54:36 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100723105436.9694A3A6902@core3.amsl.com> Date: Fri, 23 Jul 2010 03:54:36 -0700 (PDT) X-Mailman-Approved-At: Sun, 25 Jul 2010 23:33:44 -0700 Cc: hipsec@ietf.org, gonzalo.camarillo@ericsson.com Subject: [Hipsec] WG Action: RECHARTER: Host Identity Protocol (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: Fri, 23 Jul 2010 10:54:36 -0000 The Host Identity Protocol (hip) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Host Identity Protocol (hip) --------------------------------------------------- Current Status: Active Working Group Chairs: David Ward Gonzalo Camarillo Internet Area Directors: Jari Arkko Ralph Droms Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/ The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys, from which end-point identifiers are taken. The public keys are typically, but not necessarily, self generated. HIP uses existing IP addressing and forwarding for locators and packet delivery. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. The HIP WG was chartered to publish protocol specifications in documents whose quality and security properties would meet the requirements for publication as standards track documents. These specifications have been published as Experimental RFCs, because the effects of the protocol on applications and on the Internet as a whole were unknown. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. The HIP WG will now produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. The following are charter items for the working group: o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 as standards track RFCs. o Specify in a standards track RFC how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. Goals and Milestones Done Submit Native API specification to the IESG Done Submit Framework for HIP overlays specification to the IESG Done Submit Multi-hop routing mechanism for HIP Done Submit Upper-layer data transport in HIP to the IESG Sep 2010 WGLC Certs in HIP base exchange specification Sep 2010 WGLC RFC4423bis Sep 2010 WGLC RFC4843bis Sep 2010 WGLC RFC5201bis Sep 2010 WGLC RFC5202bis Oct 2010 Submit Certs in HIP base exchange specification to the IESG Oct 2010 Submit RFC4423bis to the IESG Oct 2010 Submit RFC4843bis to the IESG Oct 2010 Submit RFC5201bis to the IESG Oct 2010 Submit RFC5202bis to the IESG Dec 2010 WGLC RFC5203bis Dec 2010 WGLC RFC5204bis Dec 2010 WGLC RFC5205bis Dec 2010 WGLC the mobility portion of RFC5206bis Jan 2011 Submit RFC5203bis to the IESG Jan 2011 Submit RFC5204bis to the IESG Jan 2011 Submit RFC5205bis to the IESG Jan 2011 Submit the mobility portion of RFC5206bis to the IESG Feb 2011 WGLC RFC5770bis Feb 2011 WGLC the multihoming portion of RFC5206bis Mar 2011 Submit RFC5770bis to the IESG Mar 2011 Submit the multihoming portion of RFC5206bis to the IESG Apr 2011 Recharter or close the WG From heer@informatik.rwth-aachen.de Mon Jul 26 01:23:16 2010 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 9E3F83A6885 for ; Mon, 26 Jul 2010 01:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 sjLX79IkqQvP for ; Mon, 26 Jul 2010 01:23:15 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 3B1913A6859 for ; Mon, 26 Jul 2010 01:23:15 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L6500L1PONBY5E0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 26 Jul 2010 10:23:35 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,260,1278280800"; d="scan'208";a="66570957" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 26 Jul 2010 10:23:35 +0200 Received: from dhcp-21dd.meeting.ietf.org ([unknown] [130.129.33.221]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L6500IGSONB9U30@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 26 Jul 2010 10:23:35 +0200 (CEST) From: Tobias Heer Date: Mon, 26 Jul 2010 10:23:34 +0200 Message-id: <1FB66C6B-99BD-4372-8426-66A38AE1FEF4@cs.rwth-aachen.de> To: HIP WG X-Mailer: Apple Mail (2.1081) Subject: [Hipsec] HIP RFC5201-bis editing session 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, 26 Jul 2010 08:23:16 -0000 Hi. As previously mentioned on this list we plan some discussions on the current state and future directions for RFC5201-bis this IETF. We will meet tomorrow (Tuesday) afternoon 15:20 in the reception area. Until then I'll try to figure out where we can go to sit down and talk. Everyone is welcome. Specific topics I would like to discuss are: * Current status and history of changes * Parameter space redesign * The future role of the HIT (taking into consideration multiple HIs per host) * (whatever you bring up) The current document can be found here: http://www.ietf.org/id/draft-moskowitz-hip-rfc5201-bis-02.txt BR, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From gonzalo.camarillo@ericsson.com Mon Jul 26 23:45:46 2010 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 5BD413A69A2 for ; Mon, 26 Jul 2010 23:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.803 X-Spam-Level: X-Spam-Status: No, score=-105.803 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ibzBYOX-IQtq for ; Mon, 26 Jul 2010 23:45:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 02C2B3A67D1 for ; Mon, 26 Jul 2010 23:45:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-35-4c4e80ae38df Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DF.D0.10125.EA08E4C4; Tue, 27 Jul 2010 08:46:06 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jul 2010 08:46:05 +0200 Received: from [131.160.126.137] ([131.160.126.137]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jul 2010 08:46:05 +0200 Message-ID: <4C4E80AD.9050305@ericsson.com> Date: Tue, 27 Jul 2010 08:46:05 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2010 06:46:05.0564 (UTC) FILETIME=[62F243C0:01CB2D57] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] New WG items 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, 27 Jul 2010 06:45:46 -0000 Folks, we need WG items for our new milestones. The WG has been working on the following individual drafts, all of which are related to new milestones. Does anybody object to take them as our WG items for their respective new milestones? https://datatracker.ietf.org/doc/draft-moskowitz-hip-rfc4423-bis/ https://datatracker.ietf.org/doc/draft-moskowitz-hip-rfc5201-bis/ https://datatracker.ietf.org/doc/draft-jokela-hip-rfc5202-bis/ https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/ Cheers, Gonzalo From ari.keranen@nomadiclab.com Thu Jul 29 07:56:44 2010 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 033C63A68D9 for ; Thu, 29 Jul 2010 07:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 pWQHPl+Seoz5 for ; Thu, 29 Jul 2010 07:56:43 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id EE7043A6869 for ; Thu, 29 Jul 2010 07:56:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id EB80F4E6D4 for ; Thu, 29 Jul 2010 17:57:04 +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 jGsinwW6J6yZ for ; Thu, 29 Jul 2010 17:57:04 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 64CA24E6BF for ; Thu, 29 Jul 2010 17:57:04 +0300 (EEST) Message-ID: <4C5196C7.4090200@nomadiclab.com> Date: Thu, 29 Jul 2010 16:57:11 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Ambiguous HIP parameter names 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, 29 Jul 2010 14:56:44 -0000 Hi all, After discussing the parameter ranges, we noticed that some of the parameter names are not particularly informative and it would make sense to update them in the bis version(s). For example, from the name "HIP_SIGNATURE_2" (in RFC5201) it's not really apparent what it really does. Perhaps that should be changed into something else? Cheers, Ari From heer@informatik.rwth-aachen.de Thu Jul 29 10:11:39 2010 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 E765F3A6784 for ; Thu, 29 Jul 2010 10:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.368 X-Spam-Level: X-Spam-Status: No, score=-4.368 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 JK1ydzHlMOzu for ; Thu, 29 Jul 2010 10:11:37 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 25D473A65A5 for ; Thu, 29 Jul 2010 10:11:37 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L6B00LQJX40XPF0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 29 Jul 2010 19:12:00 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,281,1278280800"; d="scan'208";a="67063633" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 29 Jul 2010 19:12:00 +0200 Received: from dhcp-21dd.meeting.ietf.org ([unknown] [130.129.33.221]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L6B00KTXX40HB60@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 29 Jul 2010 19:12:00 +0200 (CEST) From: Tobias Heer In-reply-to: <4C5196C7.4090200@nomadiclab.com> Date: Thu, 29 Jul 2010 19:12:03 +0200 Message-id: References: <4C5196C7.4090200@nomadiclab.com> To: Ari Keranen X-Mailer: Apple Mail (2.1081) Cc: HIP Subject: Re: [Hipsec] Ambiguous HIP parameter names 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, 29 Jul 2010 17:11:40 -0000 Am 29.07.2010 um 16:57 schrieb Ari Keranen: > Hi all, > > After discussing the parameter ranges, we noticed that some of the parameter names are not particularly informative and it would make sense to update them in the bis version(s). For example, from the name "HIP_SIGNATURE_2" (in RFC5201) it's not really apparent what it really does. Perhaps that should be changed into something else? > Good point. Tobias > > Cheers, > Ari > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From heer@informatik.rwth-aachen.de Thu Jul 29 10:28:42 2010 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 062A328C1DD for ; Thu, 29 Jul 2010 10:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.476 X-Spam-Level: X-Spam-Status: No, score=-4.476 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 e+kP7PcKadDa for ; Thu, 29 Jul 2010 10:28:40 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 78C0A28C0DB for ; Thu, 29 Jul 2010 10:28:40 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L6B00LWVXWGXPF0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 29 Jul 2010 19:29:04 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,281,1278280800"; d="scan'208";a="67064981" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 29 Jul 2010 19:29:03 +0200 Received: from dhcp-21dd.meeting.ietf.org ([unknown] [130.129.33.221]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L6B00K22XWFHB70@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 29 Jul 2010 19:29:03 +0200 (CEST) From: Tobias Heer Date: Thu, 29 Jul 2010 19:29:06 +0200 Message-id: <661EB84D-5466-4893-BA7D-1A9A4B73F4CC@cs.rwth-aachen.de> To: HIP WG X-Mailer: Apple Mail (2.1081) Subject: [Hipsec] Parameter space layout and significant change in wording 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, 29 Jul 2010 17:28:42 -0000 Hi! We were discussing the parameter space layout during the 5201-bis discussion session. The result was the following. I marked the changes with "!" 0 - 1023 Handshake 1024 - 2047 Reserved ! 2048 - 8191 Signed parameters allocated through specification documents* ! 8192 - 61439 Reserved ! 61440 - 62463 Signatures and (signed) MACs ! 62464 - 63487 Parameters that are neither signed nor MACed* 63488 - 64511 Rendezvous and relaying ! 64512 - 65023 Parameters that not signed* ! 65024 - 65535 Reserved The rationale behind the changes was to have a non-BEX block and reserved blocks for future expansion in all vital spaces. The parts marked with * are the sub-spaces that are intended for extensions, etc. that do not strictly extend or modify the handshake. Any comments or objections? IMPORTANT: There is a slight change in wording to make creating HIP derivatives without signature less complex. I changed the "Signatures and MACs" to "Signatures and (signed) MACs" and "Parameters that are not signed" to "Parameters that are neither signed nor MACed". This will not change anything in the BEX (most importantly it will stay SIGMA compliant) but it avoids redefinition of parameters with different parameter numbers for DEX and other variants without signature capabilities. This is to allow a movement towards a "family" of interoperable HIP protocols. I would appreciate discussion and comments on this step on the list. BR, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From ari.keranen@nomadiclab.com Fri Jul 30 05:18:47 2010 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 9B9A43A698B for ; Fri, 30 Jul 2010 05:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 IhTEWy77cWfW for ; Fri, 30 Jul 2010 05:18:44 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 7445D3A698E for ; Fri, 30 Jul 2010 05:18:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 45A154E6D4; Fri, 30 Jul 2010 15:19:03 +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 yn5Y7HyVReOG; Fri, 30 Jul 2010 15:19:02 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 92A2D4E6BF; Fri, 30 Jul 2010 15:19:02 +0300 (EEST) Message-ID: <4C52C33E.3030700@nomadiclab.com> Date: Fri, 30 Jul 2010 14:19:10 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Tobias Heer References: <661EB84D-5466-4893-BA7D-1A9A4B73F4CC@cs.rwth-aachen.de> In-Reply-To: <661EB84D-5466-4893-BA7D-1A9A4B73F4CC@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] Parameter space layout and significant change in wording 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, 30 Jul 2010 12:18:47 -0000 Hi, 29.7.2010 19:29, Tobias Heer kirjoitti: > We were discussing the parameter space layout during the 5201-bis discussion session. > The result was the following. I marked the changes with "!" > > 0 - 1023 Handshake > 1024 - 2047 Reserved > ! 2048 - 8191 Signed parameters allocated through specification documents* > ! 8192 - 61439 Reserved > ! 61440 - 62463 Signatures and (signed) MACs > ! 62464 - 63487 Parameters that are neither signed nor MACed* > 63488 - 64511 Rendezvous and relaying > ! 64512 - 65023 Parameters that not signed* > ! 65024 - 65535 Reserved > > The rationale behind the changes was to have a non-BEX block and > reserved blocks for future expansion in all vital spaces. The parts > marked with * are the sub-spaces that are intended for extensions, > etc. that do not strictly extend or modify the handshake. Any > comments or objections? > Makes sense. Some of the old (HIP v1) parameters (FROM, RVS_HMAC, VIA_RVS, RELAY_HMAC, ROUTE_VIA) will end up in the last Reserved slot with these ranges, but those docs can be bis'ed where needed. > IMPORTANT: There is a slight change in wording to make creating HIP > derivatives without signature less complex. I changed the "Signatures > and MACs" to "Signatures and (signed) MACs" and "Parameters that are > not signed" to "Parameters that are neither signed nor MACed". This > will not change anything in the BEX (most importantly it will stay > SIGMA compliant) but it avoids redefinition of parameters with > different parameter numbers for DEX and other variants without > signature capabilities. This is to allow a movement towards a > "family" of interoperable HIP protocols. I would appreciate > discussion and comments on this step on the list. Sounds like a good approach. Cheers, Ari