gmane.ietf.hipsec

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

Miika Komu — 2013-05-19T20:03:52

Hi,

On 05/17/2013 02:03 PM, Gonzalo Camarillo wrote:

this work has already been iterated in the working group, and I recall 
you had a prototype, so I'd support going forward with this work.

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

Gonzalo Camarillo — 2013-05-17T11:03:24

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

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

Julien Laganier — 2013-05-07T22:10:25

Hi,

I believe I have addresses all the WGLC comments so the document
should be ready to go to IESG together with 5201bis and 5202bis.

--julien

On Mon, May 6, 2013 at 10:20 AM,  <internet-drafts< at >ietf.org> wrote:

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

2013-05-06T17:20:11

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 addre

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

Ari Keranen — 2013-05-06T14:45:11

Hi all,

This update aligns the RELOAD HIP BONE instance spec with the -20 
version of the RELOAD spec (now in IESG review). Also added some 
editorial clarifications.


Cheers,
Ari

On 5/6/13 5:39 PM, internet-drafts< at >ietf.org wrote:

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

2013-05-06T14:39:24

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/ht

Biggest Fake Conference in Computer Science

2013-04-27T16:59:07

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

Paper: Adoption barriers of HIP

Levä Tapio — 2013-04-12T10:39:03

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 ide

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

Samu Varjonen — 2013-04-05T07:17:09

3.4.2013 15:44, Miika Komu kirjoitti:

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.

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

Miika Komu — 2013-04-03T12:44:56

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:

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

Samu Varjonen — 2013-04-03T08:13:39

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< at >ietf.org wrote:

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

2013-04-01T18:30:23

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
   c

Re: HIP-based anycast

Miika Komu — 2013-04-01T08:36:17

Ok Julien, no actions needed then. Thanks!

On 01/04/13 04:17, Julien Laganier wrote:
>

Re: HIP-based anycast

Julien Laganier — 2013-04-01T01:17:08

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 <mkomu< at >cs.hut.fi> wrote:

Re: HIP-based anycast

Miika Komu — 2013-03-30T19:57:08

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:

Re: HIP-based anycast

Julien Laganier — 2013-03-28T23:36:54

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 <mkomu< at >cs.hut.fi> wrote:

Re: WGLC: draft-ietf-hip-rfc4843-bis

Julien Laganier — 2013-03-28T21:01:44

Hi Tom,

Thanks for reviewing the document. My comments inline below:

On Mon, Mar 11, 2013 at 2:14 PM, Henderson, Thomas R
<thomas.r.henderson< at >boeing.com> wrote:

I'd rather not change the statement that they should not appear in
actual IPv6 headers as this could become a red herring to our argument
that ORCHID allocation is useful and _harmless_. As per your comment
below a will replace vanilla by normal or regular.


Ok.


While I agree we are no longer talking about experimental, are we sure
we want to leave out the recommendation that the ORCHID prefix not be
hardcoded into data path? Seems to me it is still valuable.


Ok.


Ok.


Ok. Will move to appendix, and add the key reuse caveat, as well as
remove the discussion on the node-wide database.


Ok.


Ok. Will replace by normal or regular.


I guess by design, since we are not providing the means to route at
the IP layer - they do not have prefix on which longest prefix match
can occur...


Ok.


Ok.

--julien

Re: WGLC: draft-ietf-hip-rfc5202-bis

Henderson, Thomas R — 2013-03-28T20:25:57



It could be done with reference to published RFCs, just to declare that it is out of scope of this document and handled elsewhere.

e.g. something like this at the end of Introduction, with two informative references.

"HIP and ESP traffic have known issues with middlebox traversal [RFC5207].  Other specifications exist for operating HIP and ESP over UDP ([RFC5770] is an experimental specification, and others are being developed).  Middlebox traversal is out of scope for this document."

Re: WGLC: draft-ietf-hip-rfc5202-bis

Ari Keränen — 2013-03-28T19:22:40

Hi,

On 3/26/13 3:44 PM, Miika Komu wrote:

I think mentioning this possibility could make sense since "HIP doesn't 
work through NATs" seems to be one of the biggest misconceptions people 
have had about HIP. However, I don't see any reason why it should be a 
normative reference, so informative (and hence not blocking) would be fine.


Cheers,
Ari

Re: WGLC: draft-ietf-hip-rfc5202-bis

Miika Komu — 2013-03-26T13:44:21

Hi,

On 03/26/2013 01:18 PM, Petri Jokela wrote:

how are the RFCs bundled together for the standards track, or would this 
create an undesired dependencies? If it creates such a dependency, can 
it be avoided by referencing NAT specification as informational?

Re: WGLC: draft-ietf-hip-rfc5202-bis

Petri Jokela — 2013-03-26T11:18:11

Hi, 

Comments and questions follow. If I haven't commented, I have just changed it in the draft. 

The current version can be found from:

http://jokela.org/ietf/draft-ietf-hip-rfc5202-bis-02-pre1.txt



I think there was a reason to do this, but I have no idea what it was. Does it make any sense, or shall we delete it?


Should the first value be from the beginning of the area and the second one from somewhere in the middle? I don't know if it does matter, but originally they were selected with that principle. So, 2049 and 3072 perhaps?

I moved the last sentence to follow the table. 


I removed the paragraph. 


Listed the following as mandatory:

            Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and
            NULL with HMAC-SHA-256.



I hope I changed them correctly everywhere. 


Changed now to AES-128-CBC + HMAC-SHA-256. Or should it be AES-256-CBC?


Here I cannot say anything. Any opinions from others?


Petri