Subject: [Hipsec] Follow-up on 4843bis / ORCHIDv2

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 30 Mar 2010 14:28:45 -0700

Folks,

As proposed at last IETF meeting, it seems we have a way forward with 4843bis:

1. HIP WG to have a 4843bis deliverable that introduces crypto-agility
   - Request permanent allocation of a new /28 prefix for ORCHIDv2
   - Introduces ORCHIDv2 Generation Algorithm (OGA), defined in a given Context 
	 - (e.g. HIP in RFC5201 bis)
   - Define new ORCHIv2 Generation Procedure:
        Input := any bitstring 
        ORCHID Input := Context ID | Input 
        ORCHID Ouput := OGA( ORCHID Input ) 
        ORCHID := Prefix | OGA Type | Encode_96( ORCHID Ouput)

=> question mark: Do we let the current 2001:10::/28 allocation expire? I recommend we do as it will make it easier to obtain a permanent allocation.

2. HIP WG to allocate OGA Type 1 as SHA1 in 5201bis and keep other values as unallocated, allocation requiring IETF specification.

=> question mark: Do we start with SHA-256 instead?

--julien

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 30 Mar 2010 14:36:17 -0700

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Laganier, Julien
> Sent: Tuesday, March 30, 2010 2:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Hipsec] Follow-up on 4843bis / ORCHIDv2
>
> Folks,
>
> => question mark: Do we let the current 2001:10::/28
> allocation expire? I recommend we do as it will make it
> easier to obtain a permanent allocation.

+1

>
> 2. HIP WG to allocate OGA Type 1 as SHA1 in 5201bis and keep
> other values as unallocated, allocation requiring IETF specification.
>

I would be happy to delegate the question to the crypto forum or other experts, but my impression is that SHA-1 is already being phased out elsewhere and that existing libraries typically have SHA-256 support.

Tom

---

From: Miika Komu <[email-masked]>
Date: Wed, 31 Mar 2010 07:11:45 +0300

On 31/03/10 00:36, Henderson, Thomas R wrote:

Hi,

>> -----Original Message----- From: [email-masked]
>> Sent: Tuesday, March 30, 2010 2:29 PM To: [email-masked] Cc:
>> [email-masked] Subject: [Hipsec] Follow-up on 4843bis
>> / ORCHIDv2
>>
>> Folks,
>>
>> 1. HIP WG to have a 4843bis deliverable that introduces
>> crypto-agility - Request permanent allocation of a new /28 prefix
>> for ORCHIDv2 - Introduces ORCHIDv2 Generation Algorithm (OGA),
>> defined in a given Context - (e.g. HIP in RFC5201 bis) - Define new
>> ORCHIv2 Generation Procedure: Input := any bitstring ORCHID Input
>> := Context ID | Input ORCHID Ouput := OGA( ORCHID Input ) ORCHID :=
>> Prefix | OGA Type | Encode_96( ORCHID Ouput)
>>
>> =>  question mark: Do we let the current 2001:10::/28 allocation
>> expire? I recommend we do as it will make it easier to obtain a
>> permanent allocation.
>
> +1

+1

>> 2. HIP WG to allocate OGA Type 1 as SHA1 in 5201bis and keep other
>> values as unallocated, allocation requiring IETF specification.
>>
> I would be happy to delegate the question to the crypto forum or
> other experts, but my impression is that SHA-1 is already being
> phased out elsewhere and that existing libraries typically have
> SHA-256 support.

I was following discussion of other people in the IETF and their opinion 
seemed to be that...

* SHA-256 may be an overkill for sensors
* Attacks on SHA1 are collision attacks where as we need just the 
preimage property

For further information, please refer to:

http://tools.ietf.org/search/rfc4270

---

From: Varjonen Samu <[email-masked]>
Date: Wed, 31 Mar 2010 09:52:40 +0300

+1
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: [email-masked]
Date: Wed, 31 Mar 2010 16:36:07 +0800

Does ORCHID consider any commercial deployment requirements?
If HIP could be commercial deployed, HIP ID should be divided into many 
sub-pieces and allocated to service providers or other organizations .

Russell Wang

Varjonen Samu <[email-masked]> 
发件人:  [email-masked]
2010-03-31 14:52

收件人
[email-masked]
抄送
[email-masked]
主题
Re: [Hipsec] Follow-up on 4843bis / ORCHIDv2

+1

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Tobias Heer <[email-masked]>
Date: Wed, 31 Mar 2010 13:26:13 +0200

Hello Russel, 

> sub-pieces and allocated to service providers or other organizations .
This might be important for future consideration, however, at the moment the namespace of the HIT is flat and does not allow that. However, the new design of the ORCHID can allow for such hierarchy by implementing a new OGA type that specifies that some of the bits in the orchid should be interpreted as organization ID. However, this has to be thought through thoroughly since it occupies at least one of the few OGA type IDs we have to our avail.

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

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 31 Mar 2010 08:35:31 -0700

Maybe I'm blunt, but IMHO HIP identifiers are flat. If hierarchical allocation and management of identifier is a required feature, DNS names look like a better fit than Host Identities / Tags. There's already been some work on name-based sockets, e.g., see this paper from Christian Vogt.

<http://christianvogt.mailup.net/pub/2009/vogt-2009-name-oriented-sockets.pdf>

[email-masked] wrote:
> If HIP could be commercial deployed, HIP ID should be divided into many sub-pieces
> and allocated to service providers or other organizations . 
>
>
> Russell Wang

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 31 Mar 2010 08:37:37 -0700

Miika Komu wrote:
> [...]

I agree that we do not care about collision attacks. (And the day where there are practical attacks on SHA1's preimage resistance, the world will have quite a bigger problem than upgrading ORCHIDv2's OGA for HIP ;-)
 
> http://tools.ietf.org/search/rfc4270

Right, good read.

--julien

---

From: [email-masked]
Date: Thu, 1 Apr 2010 09:11:11 +0800

The flat assumption maybe enough for experiment, but we are pushing HIP 
into a PS status, so I think we should make it is ready for commercial.
Assuming that an ISP want to deploy a HIP network, he must consider of 
interworking with IPV6 network, so the hip prefix must be annouced as 
normal ipv6 prefix amongst the routers. If there are more than one ISP 
have deployed independent public hip network, the flat hip address space 
will introduce routing conflicts.
So maybe a hip adress assignment authority is required, and which bits 
represent the organization should be explicitly defined.
Or maybe I'm wrong?

Russell Wang

"Laganier, Julien" <[email-masked]> 
2010-03-31 23:35

收件人
"[email-masked]" <[email-masked]>, Varjonen Samu 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: [Hipsec] Follow-up on 4843bis / ORCHIDv2

Maybe I'm blunt, but IMHO HIP identifiers are flat. If hierarchical 
allocation and management of identifier is a required feature, DNS names 
look like a better fit than Host Identities / Tags. There's already been 
some work on name-based sockets, e.g., see this paper from Christian Vogt.

<
http://christianvogt.mailup.net/pub/2009/vogt-2009-name-oriented-sockets.pdf

> If HIP could be commercial deployed, HIP ID should be divided into many 
sub-pieces

---

From: Miika Komu <[email-masked]>
Date: Thu, 01 Apr 2010 07:40:48 +0300

On 04/01/2010 04:11 AM, [email-masked] wrote:

Hi,

the orchid prefix is not routable in the same way that other IPv6
addresses are. Addresses with the orchid prefix are virtual addresses
similar to the ones used e.g. in VPNs and other tunnel mechanisms. So
they should not be advertised e.g. with BGP. However, they can be
advertised in DNS in new HI records.

> *"Laganier, Julien" <[email-masked]>*
> 
> 2010-03-31 23:35
> 
> 	
> 收件人