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

[Robert Moskowitz <[e-mail]>]

On 03/31/2010 04:36 AM, [e-mail] wrote:
>
> 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 .

Commerical deployment requirements  do not require hierarchical HITS.  I 
can show this by example.

But I agree there are places for them.  As such it should a separate 
ORCHID prefix, and most likely its own draft.

Go back to my early HIP drafts, they can be found in:   
http://tools.ietf.org/id/draft-*-hip-

For example:  http://tools.ietf.org/id/draft-moskowitz-hip-09.txt

In fact the Host Assigning Authority (HAA) field can be found in the 
older drafts like:

http://tools.ietf.org/id/draft-moskowitz-hip-04.txt

All the moskowit-hip drafts are still there, so you can see my early 
attempts.

But we figured out that hierarchical HITs will not be needed for most 
usage, and so we have dropped them from the basic documents.

>
>
> Russell Wang
>
>
>
> *Varjonen Samu <[e-mail]>*
> ???:  [e-mail]
>
> 2010-03-31 14:52
>
> 	
> ???
> 	[e-mail]
> ??
> 	[e-mail]
> ??
> 	Re: [Hipsec] Follow-up on 4843bis / ORCHIDv2
>
>
>
> 	
>
>
>
>
>
> Miika Komu wrote:
> > On 31/03/10 00:36, Henderson, Thomas R wrote:
> >
> > Hi,
> >
> >>> -----Original Message----- From: [e-mail]
> >>> [mailto:[e-mail]] On Behalf Of Laganier, Julien
> >>> Sent: Tuesday, March 30, 2010 2:29 PM To: [e-mail] Cc:
> >>> [e-mail] Subject: [Hipsec] Follow-up on 4843bis
> >>> / ORCHIDv2
> >>>
> >>> 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.
> >>
> >> +1
> >
> > +1
> +1
> >
> >>> 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?
> >>
> >> 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
> > _______________________________________________
> > Hipsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hipsec
>
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec
>
>
>
> --------------------------------------------------------
> 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.
>    
>
>
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec
>