IETF Host Identity Protocol (HIP) mailing list ()

Miika Komu | 1 Dec 2007 01:13

Picon

Picon

RE: Re: API draft

On Thu, 29 Nov 2007, Henderson, Thomas R wrote:

Hi,

>>> Miika, some responses below:
>>>
>>>>
>>>> Added more text to section 3.2. "Interaction with the Resolver":
>>>>
>>>>     The extensions in this document focus on the use of the
>>>> resolver to
>>>>     map host names to HITs and locators in HIP-aware
>>>> applications.  The
>>>>     resolver associates implicitly the the HIT with the locator(s).
>>>>     However, it is possible that an application operates
>>>> directly with a
>>>>     peer HIT without interacting with the resolver.  In such
>>>> a case, the
>>>>     application may resort to the system to map the peer
>> HIT to an IP
>>>>     address.  Alternatively, the application can explicitly
>>>> map the HIT
>>>>     to an IP address as specified in
>>>> [I-D.ietf-shim6-multihome-shim-api].
>>>>     Both of these two approaches may be more prone to errors
>>>> than the use
>>>>     resolver with host names.  Hence, HIP-aware applications should
>>>>     prefer to use the resolver with host names.
>>>
>>> Can you specify which errors the resolver-less approach is

(Continue reading)

Gonzalo Camarillo | 4 Dec 2007 17:01

Picon

Chair slides

Folks,

you can find the chair slides we will use in today's face-to-face 
meeting under the following link:

http://www3.ietf.org/proceedings/07dec/slides/hip-0.ppt

This is the link to our agenda:
http://www3.ietf.org/proceedings/07dec/agenda/hip.html

Cheers,

Gonzalo
HIP WG co-chair

Andrew McGregor | 5 Dec 2007 01:10

Picon

Re: API draft

I have a question: is this draft coherent in the presence of RFC  
5014?  Should there be a few values defined to fit into the RFC 5014  
framework?

Andrew

On 22/08/2007, at 4:33 AM, Gonzalo Camarillo wrote:

> Folks,
>
> a few months ago, we had some discussions about the API draft. Miika  
> contacted the APPS area folks and got some feedback from them. With  
> that feedback, he has generated a new revision of the draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt
>
> The discussions with the APPS area folks are documented at:
>
> http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html
>
> http://www1.ietf.org/mail-archive/web/discuss/current/msg00755.html
>
>
> I would like people to have a look at this draft and send comments  
> to the list. Note that our plan was, and still is, to have this  
> draft ready for publication request by the end of the year.
>
> There were also discussions on producing a more long-term API at  
> some point... but that may fall under the scope of the RG instead.
>

(Continue reading)

Miika Komu | 5 Dec 2007 01:47

Picon

Picon

Re: API draft

On Tue, 4 Dec 2007, Andrew McGregor wrote:

Hi Andrew,

good point. The socket options don't seem to apply to HIP. Do you think 
that this should be mentioned in the draft?

The flag size extension applies to the draft. How commonly are AI_EXTFLAGS 
supported in practise? At leat my Ubuntu/Gutsy does not seem to support 
it.

> I have a question: is this draft coherent in the presence of RFC 5014? 
> Should there be a few values defined to fit into the RFC 5014 framework?
>
> Andrew
>
> On 22/08/2007, at 4:33 AM, Gonzalo Camarillo wrote:
>
>> Folks,
>> 
>> a few months ago, we had some discussions about the API draft. Miika 
>> contacted the APPS area folks and got some feedback from them. With that 
>> feedback, he has generated a new revision of the draft:
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt
>> 
>> The discussions with the APPS area folks are documented at:
>> 
>> http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html
>>

(Continue reading)

Pekka Nikander | 5 Dec 2007 08:57

Minor correction to hip-base

draft-hip-base states today as follows:

>    Responder's HIT Hash Algorithm (RHASH):   hash algorithm used for
>       various hash calculations in this document.  The algorithm is  
> the
>       same as is used to generate the Responder's HIT.  RHASH can be
>       determined by inspecting the Prefix of the ORCHID (HIT).  The
>       Prefix value has a one-to-one mapping to a hash function.

RFC 4843 states, on the other hand, as follows:

>  Hash_function   : The one-way hash function (i.e., hash function with
>                      pre-image resistance and second pre-image
>                      resistance) to be used according to the document
>                      defining the context usage identified by the
>                      Context ID.  For example, the current version of
>                      the HIP specification defines SHA1 [RFC 3174] as
>                      the hash function to be used to generate ORCHIDs
>                      used in the HIP protocol [HIP-BASE].

That is, in RFC 4843 RHASH is identified by the Context ID, which is,
in turn, defined in hip-base.

So, the definition of RHASH needs to be updated as follows:

    Responder's HIT Hash Algorithm (RHASH):   hash algorithm used for
       various hash calculations in this document.  The algorithm is the
       same as is used to generate the Responder's HIT.  RHASH is
       defined by the Orchid Context ID.  For HIP, the present RHASH
       algorithm is defined in Section 3.2.  A future version of HIP

(Continue reading)

Tobias Heer | 5 Dec 2007 09:21

Picon

Picon

Some concerns regarding legacy NAT traversal solution

Hello,

After following the discussions about HIP, ICE/STUN, and NAT  
traversal today in the WG, I had some concerns regarding possible  
solutions. Of course, I trust in the judgement of the NAT team (you  
have all been working on the issue for quite some time), however, I  
wonder how a possible solution could (will) look like. I'm not asking  
for details about an yet unspecified solution but I'm rather  
interested in the design space (specifically what tradeoffs seem  
acceptable/realistic). I'm specially interested in the opinion of the  
TURN people in the design team as you probably have the best  
knowledge to answer the questions.

In case STUN will be used for HIP, will there be a penalty in terms  
of RTTs for running the additional protocol (first one, then the  
other, or partially parallel)? If yes, will this additional time also  
be required if no NAT is present (e.g. when moving from behind a NAT  
to an un-NATed location)?

Will STUN replace parts of the BEX or/and UPDATE procedure for  
optimizing RTTs? If yes, how will these changes look like? Will  
existing work based on HIP still be valid or will we have to live  
with an entirely new BEX or UPDATE message exchange? Will things like  
HIP aware NATs / Firewalls, etc. be harder to implement because they  
must support both (STUN + HIP)?

Concluding, is consistency with the MM and Base draft one of the  
design goals of the NAT design team or may parts of these documents  
be obsoleted by the NAT traversal approach?

(Continue reading)

Mark Townsley | 5 Dec 2007 16:47

Picon

Re: Minor correction to hip-base


This looks fairly important, so I have added it as an RFC Editor's note 
- it should be fixed when he RFC Editor edits the document. WG, if there 
is any objection to this change, please let me know ASAP.

- Mark

Pekka Nikander wrote:
> draft-hip-base states today as follows:
>
>>    Responder's HIT Hash Algorithm (RHASH):   hash algorithm used for
>>       various hash calculations in this document.  The algorithm is the
>>       same as is used to generate the Responder's HIT.  RHASH can be
>>       determined by inspecting the Prefix of the ORCHID (HIT).  The
>>       Prefix value has a one-to-one mapping to a hash function.
>
> RFC 4843 states, on the other hand, as follows:
>
>>  Hash_function   : The one-way hash function (i.e., hash function with
>>                      pre-image resistance and second pre-image
>>                      resistance) to be used according to the document
>>                      defining the context usage identified by the
>>                      Context ID.  For example, the current version of
>>                      the HIP specification defines SHA1 [RFC 3174] as
>>                      the hash function to be used to generate ORCHIDs
>>                      used in the HIP protocol [HIP-BASE].
>
> That is, in RFC 4843 RHASH is identified by the Context ID, which is,
> in turn, defined in hip-base.
>

(Continue reading)

Jari Arkko | 5 Dec 2007 18:43

Re: Re: Minor correction to hip-base

The text works for me.

Jari

Mark Townsley kirjoitti:
>
> This looks fairly important, so I have added it as an RFC Editor's
> note - it should be fixed when he RFC Editor edits the document. WG,
> if there is any objection to this change, please let me know ASAP.
>
> - Mark
>
> Pekka Nikander wrote:
>> draft-hip-base states today as follows:
>>
>>>    Responder's HIT Hash Algorithm (RHASH):   hash algorithm used for
>>>       various hash calculations in this document.  The algorithm is the
>>>       same as is used to generate the Responder's HIT.  RHASH can be
>>>       determined by inspecting the Prefix of the ORCHID (HIT).  The
>>>       Prefix value has a one-to-one mapping to a hash function.
>>
>> RFC 4843 states, on the other hand, as follows:
>>
>>>  Hash_function   : The one-way hash function (i.e., hash function with
>>>                      pre-image resistance and second pre-image
>>>                      resistance) to be used according to the document
>>>                      defining the context usage identified by the
>>>                      Context ID.  For example, the current version of
>>>                      the HIP specification defines SHA1 [RFC 3174] as
>>>                      the hash function to be used to generate ORCHIDs

(Continue reading)

Julien Laganier | 5 Dec 2007 19:08

Re: Re: Minor correction to hip-base

Mark,

The change is fine with me. 

Pekka, thanks for catching this!

--julien

On Wednesday 05 December 2007, Mark Townsley wrote:
> This looks fairly important, so I have added it as an RFC Editor's
> note - it should be fixed when he RFC Editor edits the document. WG,
> if there is any objection to this change, please let me know ASAP.
>
> - Mark
>
> Pekka Nikander wrote:
> > draft-hip-base states today as follows:
> >>    Responder's HIT Hash Algorithm (RHASH):   hash algorithm used
> >> for various hash calculations in this document.  The algorithm is
> >> the same as is used to generate the Responder's HIT.  RHASH can be
> >> determined by inspecting the Prefix of the ORCHID (HIT).  The
> >> Prefix value has a one-to-one mapping to a hash function.
> >
> > RFC 4843 states, on the other hand, as follows:
> >>  Hash_function   : The one-way hash function (i.e., hash function
> >> with pre-image resistance and second pre-image resistance) to be
> >> used according to the document defining the context usage
> >> identified by the Context ID.  For example, the current version of
> >> the HIP specification defines SHA1 [RFC 3174] as the hash function
> >> to be used to generate ORCHIDs used in the HIP protocol

(Continue reading)

Miika Komu | 5 Dec 2007 20:49

Picon

Picon

Re: Some concerns regarding legacy NAT traversal solution

On Wed, 5 Dec 2007, Tobias Heer wrote:

Hi Tobias,

> In case STUN will be used for HIP, will there be a penalty in terms of RTTs 
> for running the additional protocol (first one, then the other, or partially 
> parallel)? If yes, will this additional time also be required if no NAT is 
> present (e.g. when moving from behind a NAT to an un-NATed location)?

Yes there is some penalty. This is what we discussed earlier on nat design 
team list but it is somewhat modified (SEQ needs a separate ACK):

STUN-based approach:

L                       Relay(R)                         R
| UPDATE(LOCATOR,SEQ, SPI) |                             |
+------------------------->+                             |
|                          |                             |
|                          +---------------------------->|
|                          |                             |
|                          | UPDATE(LOCATOR,SPI,SEQ,ACK) |
|                          |<----------------------------|
|<-------------------------+                             |
|                          |                             |
|    UPDATE(ACK)           |                             |
+------------------------->|                             |
|                          |                             |
|                          +---------------------------->|
|                          |                             |
|               ICE connectivity tests                   |

(Continue reading)

Group

gmane.ietf.hipsec.

Project Web Page

IETF Host Identity Protocol (HIP) mailing list ()

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6

Articles in period: 50

December 2007

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

WGLC: draft-ietf-hip-reload-instance-07 (17 May 2013)
I-D Action: draft-ietf-hip-rfc4843-bis-04.txt (6 May 2013)
I-D Action: draft-ietf-hip-reload-instance-07.txt (6 May 2013)
Biggest Fake Conference in Computer Science (27 Apr 2013)
Paper: Adoption barriers of HIP (12 Apr 2013)
I-D Action: draft-ietf-hip-rfc6253-bis-00.txt (1 Apr 2013)
WGLC: draft-ietf-hip-rfc4843-bis (26 Feb 2013)
WGLC: draft-ietf-hip-rfc5202-bis (26 Feb 2013)
WG draft status check (25 Feb 2013)
I-D Action: draft-ietf-hip-rfc5201-bis-11.txt (25 Feb 2013)
ORCHID 2001:10::/28 allocation expires in March 2014 (22 Feb 2013)
I-D Action: draft-ietf-hip-multihoming-02.txt (16 Jan 2013)
I-D Action: draft-ietf-hip-rfc5206-bis-05.txt (16 Jan 2013)
issue resolution on RFC5201-bis (2 Jan 2013)
I-D Action: draft-ietf-hip-native-nat-traversal-04.txt (14 Dec 2012)
HIP-based anycast (27 Nov 2012)
Network-bound puzzles for HIP? (27 Nov 2012)
update to RFC5201-bis, and open issues (26 Nov 2012)
I-D Action: draft-ietf-hip-rfc5201-bis-10.txt (26 Nov 2012)
Just recovered from killed notebook (19 Nov 2012)
5201-bis LSI address allocation (9 Nov 2012)

Archives

6	May 2013
8	April 2013
9	March 2013
9	February 2013
5	January 2013
10	December 2012
15	November 2012
26	October 2012
40	September 2012
6	August 2012
17	July 2012
13	June 2012
5	May 2012
10	April 2012
9	March 2012
4	February 2012
6	January 2012
5	December 2011
7	November 2011
8	October 2011
21	September 2011
1	August 2011
9	July 2011
5	May 2011
12	April 2011
32	March 2011
33	February 2011
41	January 2011
16	December 2010
17	November 2010
40	October 2010
26	September 2010
15	August 2010
45	July 2010
46	June 2010
68	May 2010
78	April 2010
48	March 2010
55	February 2010
68	January 2010
75	December 2009
10	November 2009
23	October 2009
11	September 2009
40	August 2009
101	July 2009
22	June 2009
13	May 2009
2	April 2009
20	March 2009
6	February 2009
5	January 2009
15	November 2008
16	October 2008
13	September 2008
12	August 2008
34	July 2008
7	June 2008
10	May 2008
14	April 2008
1	March 2008
11	February 2008
22	January 2008
50	December 2007
26	November 2007
6	October 2007
63	September 2007
20	August 2007
20	July 2007
103	June 2007
28	May 2007
31	April 2007
31	March 2007
17	February 2007
10	January 2007
2	December 2006
7	November 2006
12	October 2006
13	September 2006
12	August 2006
7	July 2006
22	June 2006
26	May 2006
71	April 2006
40	March 2006
19	February 2006
13	January 2006
7	December 2005
48	November 2005
42	October 2005
24	September 2005
47	August 2005
74	July 2005
48	June 2005
48	May 2005
21	April 2005
53	March 2005
46	February 2005
33	January 2005
29	December 2004
48	November 2004
133	October 2004
67	September 2004
12	August 2004
58	July 2004
69	June 2004
50	May 2004
109	April 2004
56	March 2004

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template