Re: Re: API draft

Hi Miika,

It was a bit unclear to me from the latest revision of the draft 
(03-pre3) how the application can now create a HIT to locator mapping in 
case they are found by some other means than DNS. Is the idea now to use 
shim6-multihome-shim-api-03 draft's setsockopt with SHIM_LOC_PEER_PREF 
or similar? I guess that's in line with the discussion we had earlier 
but I'd rather see it stated more explicitly.

Then some minor issues and nits (they are in the order as they appear in 
the draft):

The wrong definition of Locator is still in the Table 1 (now it's 
defined twice).

The draft text and the Figure 3 aren't consistent. In the text (before 
the figure) you have "hip_family", "sins_port" and "sins_hit", while in 
the Figure 3 they are apparently called "ship_family", "ship_port" and 
"ship_hit".

Is the definition of "hip_locator_t" in the Figure 3 needed anymore? If 
it is, perhaps it should be in the summary table (Table 3) too.

"The application can HIP_HIT_ "
s/can/can use the/

"The ai_family field is set to AF_HIP the addrinfo structure when"
s/AF_HIP the/AF_HIP in the/
Also, in the comments of the struct it says that the value could be 
e.g., PF_HIP. It might be better to use either AF or PF consistently.

Re: Re: API draft

On Thu, 1 Nov 2007, Ari Keränen wrote:

Ari, appreciate your comments. Some comments below.

> Hi Miika,
>
> It was a bit unclear to me from the latest revision of the draft (03-pre3) 
> how the application can now create a HIT to locator mapping in case they are 
> found by some other means than DNS. Is the idea now to use 
> shim6-multihome-shim-api-03 draft's setsockopt with SHIM_LOC_PEER_PREF or 
> similar? I guess that's in line with the discussion we had earlier but I'd 
> rather see it stated more explicitly.

When the application implements its own locator policies, it can control 
the locators bindings with SHIM_LOC_PEER_PREF socket option as defined in 
[I-D.ietf-shim6-multihome-shim-api].

> Then some minor issues and nits (they are in the order as they appear in the 
> draft):
>
> The wrong definition of Locator is still in the Table 1 (now it's defined 
> twice).

Now it is:

    | Locator | Routable IPv4 or IPv6 address used at the lower layers  |
>
> The draft text and the Figure 3 aren't consistent. In the text (before the 
> figure) you have "hip_family", "sins_port" and "sins_hit", while in the 
> Figure 3 they are apparently called "ship_family", "ship_port" and 

Re: Re: API draft

Hi Miika,

Thank you for updating the draft.  I checked it and I am basically fine with
the content of the draft.  There are some minor comments (mostly editorial).
Please find them inline:

> Host Identity Protocol                                           M. Komu
> Internet-Draft                        Helsinki Institute for Information
> Intended status: Informational                                Technology
> Expires: May 1, 2008                                    October 29, 2007
> 
> 
>    Native Application Programming Interfaces (APIs) for Host Identity
>                              Protocol (HIP)
>                       draft-ietf-hip-native-api-03
> 

(snip)

> Abstract
> 
>    This document defines extensions to the current sockets API for Host
>    Identity Protocol (HIP).  The extensions focus on the initial
>    discovery of public-key based identifiers.  Using the extensions, the
>    application can verify that the identifier is a Host Identity Tag
> 
> 
> 
> Komu                       Expires May 1, 2008                  [Page 1]
> 

Agenda requests, IETF 70

Folks,

you can send me your agenda requests if you want to present something in 
the session in Vancouver.

Thanks,

Gonzalo
HIP co-chair

Re: Re: API draft

On Sat, 10 Nov 2007, Shinta Sugimoto wrote:

> Hi Miika,
>
> Thank you for updating the draft.  I checked it and I am basically fine with
> the content of the draft.  There are some minor comments (mostly editorial).
> Please find them inline:

Thanks Shinta for the review,

I adjusted the draft according to your suggestions and the new version is 
here:

http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre5.txt

>>    | Term    | Explanation                                             |
>>    +---------+---------------------------------------------------------+
>>    | HIP     | Host Identity Protocol                                  |
>>    | Locator | Non-routable IPv4 or IPv6 address used at the lower     |
>>    |         | layers                                                  |
>
> s/Non-routable/Routable/
>
>>    | FQDN    | Fully Qualified Domain Name                             |
>
> I guess abbreviation of FQDN is widely known.
>
>>    | HIT     | Host Identity Tag, a 100-bit hash of a public key with  |
>>    |         | a 28 bit prefix                                         |
>>    | LSI     | Local Scope Identifier, a local, 32-bit descriptor for  |

Re: Re: API draft

Hi Miika,

a few comments on this pre-version.

Expand API in the Introduction as well.

Fix grammar: "The application can also to explicitly allow..."

The draft says:

"Note that the APIs specified in this document are not specific to HIP"

The 'not' should be removed (check the text I sent to the list a while 
ago, which was agreed with the ADs).

Please, fix these and submit the draft before the cut-off date. I will 
WG last call the version you submit so that the group has a last chance 
to provide comments.

Cheers,

Gonzalo

Miika Komu wrote:
> On Sat, 10 Nov 2007, Shinta Sugimoto wrote:
> 
>> Hi Miika,
>>
>> Thank you for updating the draft.  I checked it and I am basically 
>> fine with

Re: Re: API draft

On Sun, 11 Nov 2007, Gonzalo Camarillo wrote:

Hi Gonzalo,

the new version based on your comments is in here:

http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre6.txt

> Hi Miika,
>
> a few comments on this pre-version.
>
> Expand API in the Introduction as well.
>
> Fix grammar: "The application can also to explicitly allow..."

The second goal is that applications can explicitly accept
communications with unknown peer identifiers.

> The draft says:
>
> "Note that the APIs specified in this document are not specific to HIP"
>
> The 'not' should be removed (check the text I sent to the list a while ago, 
> which was agreed with the ADs).

Removed "not". Please tell explicitly if there are other problems with 
this. I mentioned this already in the summary of changes on the mailing 
list, but I removed the SHIM generalization in lack of any other concrete 
examples where the generalization could be useful. Also, I think it is 

(no subject)

_______________________________________________
Hipsec mailing list
Hipsec <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec

New HIP-related Internet draft.

Sorry for having sent the previous mail without subject. I'm  
resending it to avoid that it gets stuck in some aggressive spam  
filters. Sorry for receiving multiple copies.

There is a new HIP-related Internet draft.

Filename:	 draft-heer-hip-middle-auth
Revision:	 00
Title:		 End-Host Authentication for HIP Middleboxes
Creation_date:	 2007-11-11
WG ID:		 Independent Submission
Number_of_pages: 17

Abstract:
The Host Identity Protocol is a signaling protocol for secure
communication, mobility, and multihoming by introducing a
cryptographic namespace.  This document specifies an extension for
HIP that enables middleboxes to unambiguously verify the identities
of hosts that communicate across them.  This extension enables
middleboxes to verify the liveness and freshness of a HIP association
and, thus, enables reliable and secure access control in middleboxes.

http://www.ietf.org/internet-drafts/draft-heer-hip-middle-auth-00.txt
	
Comments are highly appreciated.

Best regards,

Tobias

--  Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

_______________________________________________
Hipsec mailing list
Hipsec <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec

_______________________________________________
Hipsec mailing list
Hipsec <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec

Re: Agenda requests, IETF 70

Gonzalo,

I'd like to present our ongoing work on integrating the concepts of the
Six/One site multi-homing solution into HIP.  A 5- to 10-minutes slot
would be sufficient.

Six/One is one of the main proposals currently being discussed in IRTF's
Routing research group.  Interested folks find the proposal here:

http://users.piuha.net/chvogt/pub/2007/draft-vogt-rrg-six-one-00.txt

Thanks!
- Christian