From mkomu@cs.hut.fi Mon Apr 1 01:36:10 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EF521F8881 for ; Mon, 1 Apr 2013 01:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDnpAuIIQk2i for ; Mon, 1 Apr 2013 01:36:09 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8158521F86B9 for ; Mon, 1 Apr 2013 01:36:09 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id AD98130830F; Mon, 1 Apr 2013 11:36:07 +0300 (EEST) Message-ID: <51594701.7080505@cs.hut.fi> Date: Mon, 01 Apr 2013 11:36:17 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Julien Laganier References: <50B48A1A.1080609@cs.hut.fi> <51574394.3070208@cs.hut.fi> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: hip WG Subject: Re: [Hipsec] HIP-based anycast X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 08:36:10 -0000 Ok Julien, no actions needed then. Thanks! On 01/04/13 04:17, Julien Laganier wrote: > Hi Miika, > > I don't think we're at a stage where it is feasible to retrofit > support for future extensions in the base HIP specifications. > > As to the group key pair, it isn't shared on the server. The anycast > group controller holds the key pair, and uses it to derive the group > anycast HIT, and issue authorization certificates to group members who > own their own individual key pairs. SPKI authorization certificates > can be used for this purpose. > > --julien > > On Sat, Mar 30, 2013 at 12:57 PM, Miika Komu wrote: >> Hi Julien, >> >> I'll have to the check the reference in more detail. Surely, shared private >> keys at the server side are certainly one possibility, but the compromise of >> a single host would then compromise the entire group? >> >> I was originally thinking that the IP address of rendezvous server would >> identify the group, but admit this can be somewhat limiting. For instance, >> an additional parameter in the I1 could identify the group. Clearly, >> multicast is outside of the scope of this WG, but I was considering if the >> specifications are future proof with such an approach since now the >> opportunistic base exchange is always terminated at the rendezvous server. >> >> P.S. I'll automatically assume this discussion shouldn't affect the specs at >> all if this topic doesn't gather too much discussion (and it's quite a late >> in process, anyway). >> >> >> On 03/29/2013 01:36 AM, Julien Laganier wrote: >>> >>> Hi, >>> >>> HIP anycast would need a HIT to identify the members of the anycast >>> group, wouldn't it? >>> >>> So why not have a key pair generated for the group, and the HIT >>> derived from the public key be the anycast HIT. One could then use the >>> group anycast key pair to sign authorization certificates granting >>> membership into the group. Similar concept has been explored for IPv6 >>> multicast and anycast group in: >>> >>> CASTELLUCCIA, C. AND MONTENEGRO, G. 2003. Securing group management in >>> ipv6 with cryptographically >>> generated addresses. In The Eighth IEEE Symposium on Computers and >>> Communications >>> (ISCC’2003). >>> >>> --julien >>> >>> >>> On Tue, Nov 27, 2012 at 1:38 AM, Miika Komu wrote: >>>> >>>> Hi, >>>> >>>> opportunistic mode with the help of a rendezvous server could be used for >>>> implementing HIP-based anycast. The current RVS specification does not >>>> allow >>>> this: >>>> >>>> http://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-02 >>>> >>>> 4.3.1. Processing Outgoing I1 Packets >>>> >>>> An initiator SHOULD NOT send an opportunistic I1 with a NULL >>>> destination HIT to an IP address that is known to be a rendezvous >>>> server address, unless it wants to establish a HIP association with >>>> the rendezvous server itself and does not know its HIT. >>>> >>>> I think we could specify either a flag in the base exchange or >>>> alternatively >>>> a special HIT encoding for the "NULL" destination HIT in the I1. What do >>>> you >>>> think? >>>> _______________________________________________ >>>> Hipsec mailing list >>>> Hipsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hipsec >>> >>> >> > From internet-drafts@ietf.org Mon Apr 1 11:30:39 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C0921F86C9; Mon, 1 Apr 2013 11:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4GFEH3Wr1YB; Mon, 1 Apr 2013 11:30:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A37C821F8782; Mon, 1 Apr 2013 11:30:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130401183023.13191.54752.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 11:30:23 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:30:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : Host Identity Protocol Certificates Author(s) : Tobias Heer Samu Varjonen Filename : draft-ietf-hip-rfc6253-bis-00.txt Pages : 11 Date : 2013-03-22 Abstract: The CERT parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and SPKI certificates. The concrete use of certificates including how certificates are obtained, requested, and which actions are taken upon successful or failed verification are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects are left to the documents that use the CERT parameter. This document updates RFC 5201. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From samu.varjonen@helsinki.fi Wed Apr 3 01:13:44 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D953C21F85A1 for ; Wed, 3 Apr 2013 01:13:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9mN6MC-8LoT for ; Wed, 3 Apr 2013 01:13:43 -0700 (PDT) Received: from argo.otaverkko.fi (argo.ipv6.otaverkko.fi [IPv6:2a02:4880:10:1000::2:25]) by ietfa.amsl.com (Postfix) with ESMTP id E7F2921F8539 for ; Wed, 3 Apr 2013 01:13:40 -0700 (PDT) Received: from [128.214.114.246] (wel-36.pc.hiit.fi [128.214.114.246]) by argo.otaverkko.fi (Postfix) with ESMTPSA id A6D0E202A9 for ; Wed, 3 Apr 2013 11:13:39 +0300 (EEST) Message-ID: <515BE4B3.5070302@helsinki.fi> Date: Wed, 03 Apr 2013 11:13:39 +0300 From: Samu Varjonen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: hipsec@ietf.org References: <20130401183023.13191.54752.idtracker@ietfa.amsl.com> In-Reply-To: <20130401183023.13191.54752.idtracker@ietfa.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-rfc6253-bis-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 08:13:44 -0000 Hi all, I have some cycles that I can use to get this document forward. This is the initial submission it does not differ from the RFC6253. What would be the next steps for this document? Has anyone raised any comments/questions that should be fixed before this can be taken forward? To my knowledge there are none. BR, Samu Varjonen On 01/04/13 21:30, 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 Certificates > Author(s) : Tobias Heer > Samu Varjonen > Filename : draft-ietf-hip-rfc6253-bis-00.txt > Pages : 11 > Date : 2013-03-22 > > Abstract: > The CERT parameter is a container for digital certificates. It is > used for carrying these certificates in Host Identity Protocol (HIP) > control packets. This document specifies the certificate parameter > and the error signaling in case of a failed verification. > Additionally, this document specifies the representations of Host > Identity Tags in X.509 version 3 (v3) and SPKI certificates. > > The concrete use of certificates including how certificates are > obtained, requested, and which actions are taken upon successful or > failed verification are specific to the scenario in which the > certificates are used. Hence, the definition of these scenario- > specific aspects are left to the documents that use the CERT > parameter. > > This document updates RFC 5201. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From mkomu@cs.hut.fi Wed Apr 3 05:45:08 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7282821F8D29 for ; Wed, 3 Apr 2013 05:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stTOoHGhvUSk for ; Wed, 3 Apr 2013 05:45:07 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 689D121F8D23 for ; Wed, 3 Apr 2013 05:44:58 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 31500308B87 for ; Wed, 3 Apr 2013 15:44:56 +0300 (EEST) Message-ID: <515C2448.7010008@cs.hut.fi> Date: Wed, 03 Apr 2013 15:44:56 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: hipsec@ietf.org References: <20130401183023.13191.54752.idtracker@ietfa.amsl.com> <515BE4B3.5070302@helsinki.fi> In-Reply-To: <515BE4B3.5070302@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 12:45:08 -0000 Hi, should we fix the CERT parameters in RFC5201-bis to certain base exchange packets? To integrate seamlessly with RFC5203-bis registration, R1-I2 is mostly likely a more ideal combination than R2-I2? On 04/03/2013 11:13 AM, Samu Varjonen wrote: > Hi all, > > I have some cycles that I can use to get this document forward. This is > the initial submission it does not differ from the RFC6253. What would > be the next steps for this document? Has anyone raised any > comments/questions that should be fixed before this can be taken > forward? To my knowledge there are none. > > BR, > Samu Varjonen > > On 01/04/13 21:30, 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 Certificates >> Author(s) : Tobias Heer >> Samu Varjonen >> Filename : draft-ietf-hip-rfc6253-bis-00.txt >> Pages : 11 >> Date : 2013-03-22 >> >> Abstract: >> The CERT parameter is a container for digital certificates. It is >> used for carrying these certificates in Host Identity Protocol (HIP) >> control packets. This document specifies the certificate parameter >> and the error signaling in case of a failed verification. >> Additionally, this document specifies the representations of Host >> Identity Tags in X.509 version 3 (v3) and SPKI certificates. >> >> The concrete use of certificates including how certificates are >> obtained, requested, and which actions are taken upon successful or >> failed verification are specific to the scenario in which the >> certificates are used. Hence, the definition of these scenario- >> specific aspects are left to the documents that use the CERT >> parameter. >> >> This document updates RFC 5201. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 > From samu.varjonen@helsinki.fi Fri Apr 5 00:17:27 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DB921F96AE for ; Fri, 5 Apr 2013 00:17:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWWUWts7c2TV for ; Fri, 5 Apr 2013 00:17:26 -0700 (PDT) Received: from argo.otaverkko.fi (argo.ipv6.otaverkko.fi [IPv6:2a02:4880:10:1000::2:25]) by ietfa.amsl.com (Postfix) with ESMTP id 1531921F96B8 for ; Fri, 5 Apr 2013 00:17:22 -0700 (PDT) Received: from [192.168.0.10] (cs181123160.pp.htv.fi [82.181.123.160]) by argo.otaverkko.fi (Postfix) with ESMTPSA id 2B5712184C for ; Fri, 5 Apr 2013 10:17:19 +0300 (EEST) Message-ID: <515E7A75.6000003@helsinki.fi> Date: Fri, 05 Apr 2013 10:17:09 +0300 From: Samu Varjonen User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: hipsec@ietf.org References: <20130401183023.13191.54752.idtracker@ietfa.amsl.com> <515BE4B3.5070302@helsinki.fi> <515C2448.7010008@cs.hut.fi> In-Reply-To: <515C2448.7010008@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 07:17:27 -0000 3.4.2013 15:44, Miika Komu kirjoitti: > Hi, > > should we fix the CERT parameters in RFC5201-bis to certain base > exchange packets? > I would not fix the packets that may use the CERT parameter. In my opinion it is the extensions, such as the registration, own business in which packet they use the CERT parameter. Fixing the packets could also be trouble some for some future extensions. I would not fix the packets but rather I would give recommendations, like the one existing one that it may not be wise to put CERT parameters into I1. > To integrate seamlessly with RFC5203-bis registration, R1-I2 is mostly > likely a more ideal combination than R2-I2? > > On 04/03/2013 11:13 AM, Samu Varjonen wrote: >> Hi all, >> >> I have some cycles that I can use to get this document forward. This is >> the initial submission it does not differ from the RFC6253. What would >> be the next steps for this document? Has anyone raised any >> comments/questions that should be fixed before this can be taken >> forward? To my knowledge there are none. >> >> BR, >> Samu Varjonen >> >> On 01/04/13 21:30, 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 Certificates >>> Author(s) : Tobias Heer >>> Samu Varjonen >>> Filename : draft-ietf-hip-rfc6253-bis-00.txt >>> Pages : 11 >>> Date : 2013-03-22 >>> >>> Abstract: >>> The CERT parameter is a container for digital certificates. It is >>> used for carrying these certificates in Host Identity Protocol (HIP) >>> control packets. This document specifies the certificate parameter >>> and the error signaling in case of a failed verification. >>> Additionally, this document specifies the representations of Host >>> Identity Tags in X.509 version 3 (v3) and SPKI certificates. >>> >>> The concrete use of certificates including how certificates are >>> obtained, requested, and which actions are taken upon successful or >>> failed verification are specific to the scenario in which the >>> certificates are used. Hence, the definition of these scenario- >>> specific aspects are left to the documents that use the CERT >>> parameter. >>> >>> This document updates RFC 5201. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-00 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From tapio.leva@aalto.fi Fri Apr 12 03:39:06 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A0821F8B13 for ; Fri, 12 Apr 2013 03:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDybBluOsvEH for ; Fri, 12 Apr 2013 03:39:05 -0700 (PDT) Received: from mx06.aalto.fi (mx06.aalto.fi [130.233.222.105]) by ietfa.amsl.com (Postfix) with ESMTP id 1F60E21F8A91 for ; Fri, 12 Apr 2013 03:39:05 -0700 (PDT) Received: from mx06.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D9F958030D for ; Fri, 12 Apr 2013 13:39:03 +0300 (EEST) Received: from EXHUB03.org.aalto.fi (exhub03.org.aalto.fi [130.233.222.116]) by mx06.aalto.fi (Postfix) with ESMTP id CFDE680309 for ; Fri, 12 Apr 2013 13:39:03 +0300 (EEST) Received: from EXMDB03.org.aalto.fi ([169.254.3.137]) by EXHUB03.org.aalto.fi ([130.233.222.116]) with mapi id 14.02.0318.001; Fri, 12 Apr 2013 13:39:03 +0300 From: =?iso-8859-1?Q?Lev=E4_Tapio?= To: "hipsec@ietf.org" Thread-Topic: Paper: Adoption barriers of HIP Thread-Index: AQHON2nzd1gdO9ZU6kiq/U5UtMnG9w== Date: Fri, 12 Apr 2013 10:39:03 +0000 Message-ID: <914E4AF9EA753942BBF6770F26EB86D4DE0ABD7C@EXMDB03.org.aalto.fi> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.233.154.111] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <52CE63AD03B1AD4E82F6197B02E36A25@aalto.fi> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Hipsec] Paper: Adoption barriers of HIP X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 10:39:06 -0000 Hi all, I would like to inform you about a paper titled as "Adoption barriers of network layer protocols: The case of host identity protocol" that was recently published in the Elsevier Computer Networks journal. The paper was authored by Tapio Lev=E4, Miika Komu, Ari Ker=E4nen and Sakari Luukkain= en and many people in the HIP (and the IETF) community were interviewed for the paper in the summer of 2011. Moreover, we gave presentations on the topic in multiple HIPRG meetings: - IETF80: http://www.ietf.org/proceedings/80/slides/HIPRG-6.pdf - IETF81: http://www.ietf.org/proceedings/81/slides/HIPRG-5.pdf - IETF82: http://www.ietf.org/proceedings/82/slides/HIPRG-5.pdf The paper is available online on http://dx.doi.org/10.1016/j.comnet.2012.11.024. In case you do not have access to the journal but are interested reading the paper, please contact me by email. Abstract of the paper: With increasing societal dependence on the Internet and new application areas emerging, the need for securing communications and identifying communication partners is expected to increase. However, the original Internet architecture is lacking these functionalities, and most of the protocols proposed to fix these issues have not been widely deployed. Often one of the reasons for such failure is that protocol designers have insufficient understanding of the potential adopters=B9 economic incentives so one may end up designing protocols based on false or inaccurate assumptions. In this paper, we analyze the Host Identity Protocol (HIP) from this viewpoint. Based on 19 expert interviews, we identify six main reasons why HIP has not been widely deployed yet. Most importantly, (1) the demand for the functionalities of HIP has been low. Where demand would have existed, substitute solutions have been favored because (2) they were earlier on the market, (3) they have relative advantage due to some design choices of HIP, (4) HIP lacks early adopter benefits necessitating costly coordination among multiple stakeholders in public deployment scenarios, and (5) people have misconceptions about the deployability of HIP. Additionally, (6) the research-mindedness of HIP developers has lead to strategic mistakes and non-optimal design choices from the perspective of deployment. We also suggest strategies that HIP developers could take to foster the adoption of HIP. Besides providing value to HIP developers, the results propose some new adoption barriers and deployment strategies that could be taken into account when designing new protocols. Finally, the article also provides a template that could be followed when studying the feasibility of other protocols. Best regards, --=20 Tapio Lev=E4 Doctoral student Network Economics Research Group Department of Communications and Networking Aalto University tapio.leva@aalto.fi +358-50-5710073 http://www.leva.fi/ From johnsonhammond2@hushmail.com Sat Apr 27 09:59:08 2013 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF00121F9835 for ; Sat, 27 Apr 2013 09:59:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7xUaAcpLpMZ for ; Sat, 27 Apr 2013 09:59:08 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9312D21F97F4 for ; Sat, 27 Apr 2013 09:59:08 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 57C4C580A4 for ; Sat, 27 Apr 2013 16:59:08 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 16:59:07 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id EB12614DBDE; Sat, 27 Apr 2013 16:59:07 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 12:59:07 -0400 To: hipsec@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427165907.EB12614DBDE@smtp.hushmail.com> Subject: [Hipsec] Biggest Fake Conference in Computer Science X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:18:18 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.