headers
Gonzalo Camarillo | 17 May 2013 13:03
Picon
Favicon

WGLC: draft-ietf-hip-reload-instance-07

Folks,

I would like to start a WGLC on the following draft. This WGLC will end
on May 31st:

http://tools.ietf.org/html/draft-ietf-hip-reload-instance-07

Please, send your comments to this list.

This draft has been waiting for the main RELOAD spec to complete for a
relatively long time. Now that RELOAD has been finally completed, we can
progress this draft. Note that this draft will be published as an
Experimental RFC and, thus, is not part of our current effort to move
the HIP specs to the standards track.

Thanks,

Gonzalo
Permalink | Reply | 1 comment |
headers
internet-drafts | 6 May 2013 19:20
Picon
Favicon

I-D Action: draft-ietf-hip-rfc4843-bis-04.txt


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           : An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)
	Author(s)       : Julien Laganier
                          Francis Dupont
	Filename        : draft-ietf-hip-rfc4843-bis-04.txt
	Pages           : 12
	Date            : 2013-05-06

Abstract:
   This document specifies an updated Overlay Routable Cryptographic
   Hash Identifiers format that obsoletes the earlier format defined in
   [RFC4843].  These identifiers are intended to be used as endpoint
   identifiers at applications and Application Programming Interfaces
   (API) and not as identifiers for network location at the IP layer,
   i.e., locators.  They are designed to appear as application layer
   entities and at the existing IPv6 APIs, but they should not appear in
   actual IPv6 headers.  To make them more like regular IPv6 addresses,
   they are expected to be routable at an overlay level.  Consequently,
   while they are considered non-routable addresses from the IPv6 layer
   point-of-view, all existing IPv6 applications are expected to be able
   to use them in a manner compatible with current IPv6 addresses.

   The Overlay Routable Cryptographic Hash Identifiers originally
   defined in [RFC4843] lacked a mechanism for cryptographic algorithm
   agility.  The updated ORCHID format specified in this document
   removes this limitation by encoding in the identifier itself an index
   to the suite of cryptographic algorithms in use.
(Continue reading)

Permalink | Reply | 1 comment |
headers
internet-drafts | 6 May 2013 16:39
Picon
Favicon

I-D Action: draft-ietf-hip-reload-instance-07.txt


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)       : Ari Keranen
                          Gonzalo Camarillo
                          Jouni Maenpaa
	Filename        : draft-ietf-hip-reload-instance-07.txt
	Pages           : 10
	Date            : 2013-05-06

Abstract:
   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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-reload-instance

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-hip-reload-instance-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-reload-instance-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
(Continue reading)

Permalink | Reply | 1 comment |
headers
johnsonhammond2 | 27 Apr 2013 18:59
Favicon

Biggest Fake Conference in Computer Science

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Levä Tapio | 12 Apr 2013 12:39
Picon

Paper: Adoption barriers of HIP

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ä, Miika Komu, Ari Keränen and Sakari Luukkainen
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¹ 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
internet-drafts | 1 Apr 2013 20:30
Picon
Favicon

I-D Action: draft-ietf-hip-rfc6253-bis-00.txt


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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gonzalo Camarillo | 26 Feb 2013 08:52
Picon
Favicon

WGLC: draft-ietf-hip-rfc4843-bis

Hi,

I would like to start a WGLC on the following draft. This WGLC will end
on March 12th:

http://datatracker.ietf.org/doc/draft-ietf-hip-rfc4843-bis/

Please, send your comments to this list.

Thanks,

Gonzalo
Permalink | Reply | 2 comments |
headers
Gonzalo Camarillo | 26 Feb 2013 08:49
Picon
Favicon

WGLC: draft-ietf-hip-rfc5202-bis

Hi,

I would like to start a WGLC on the following draft. This WGLC will end
on March 12th:

https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5202-bis/

Please, send your comments to this list.

Thanks,

Gonzalo
Permalink | Reply | 5 comments |
headers
Henderson, Thomas R | 25 Feb 2013 23:29
Picon
Favicon

WG draft status check

Gonzalo,

I closed the last remaining issues from WGLC on the 5201-bis draft, and posted a new revision (-11) today.

It seems to me that the following two drafts are ready for IESG review:
- RFC 5201-bis
- RFC 5202-bis

We need RFC 4843-bis to complete the set of base specifications, but as I mentioned in the previous post,
this appears to be ready now for WGLC and perhaps will also soon be ready for IESG review.

Could you let us know the sequence of next steps, whether to start with IESG review of RFC 5201/02 by
themselves, or hold them until 4843-bis can also be submitted with them?

As for our other drafts, my understanding of the status is as follows:
- 4423-bis has a number of unresolved comments against it; however, this is not normative specification
and although it has been associated with the above three in our charter milestones, I do not think it should
block moving forward on the other three
- Julien posted last year that bis versions of RFC5203-05 were close to being ready for WGLC, and there was
some light discussion of them and no major issues seemed to be present, so it seems to me that the WG would be
able to review them in WGLC shortly if draft updates could be posted. 
- Ari has been refreshing the RELOAD and native NAT traversal drafts waiting for review on the base
documents to clear
- we will need also to pick up the mobility, multihoming, and certs specifications, all of which I can
support if we can clear the queue of the base specs

Tom
Permalink | Reply | 1 comment |
headers
internet-drafts | 25 Feb 2013 21:56
Picon
Favicon

I-D Action: draft-ietf-hip-rfc5201-bis-11.txt


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 Version 2 (HIPv2)
	Author(s)       : Robert Moskowitz
                          Tobias Heer
                          Petri Jokela
                          Thomas R. Henderson
	Filename        : draft-ietf-hip-rfc5201-bis-11.txt
	Pages           : 125
	Date            : 2013-02-25

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gonzalo Camarillo | 22 Feb 2013 08:29
Picon
Favicon

ORCHID 2001:10::/28 allocation expires in March 2014

Folks,

note Leo's message below. He sent it to the original authors, who are
not reachable under those email addresses any longer. Please, provide
Leo with an answer.

Cheers,

Gonzalo

> -----Original Message-----
> From: Leo Vegoda
> Sent: Wednesday, February 20, 2013 10:01 AM
> To: 'pekka.nikander <at> nomadiclab.com'; 'julien.ietf <at> laposte.net';
> 'Francis.Dupont <at> fdupont.fr'
> Subject: ORCHID 2001:10::/28 allocation expires in March 2014
>
> Dear RFC 4843 Authors,
>
> 2001:10::/28 was allocated on a temporary basis in line with the
> instructions in RFC 4843. The allocation is due to expire in March
2014 and
> we plan to remove the registration for 2001:10::/28 in April 2014.
>
> I am sending this note now, so that you know we plan to remove the
> registration. The new registration procedures for the IANA IPv6 Special
> Purpose Address Registry require IETF Review for a renewal or new
> registration and as that could take some time I thought it was best to
> provide a year's notice.
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane