Subject: [Hipsec] Requesting the publication of draft-ietf-hip-native-api-07.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 20 Jul 2009 13:27:38 +0300

Folks,

the draft below includes all the comments received during its WGLC. 
Please, have a final look at it because we intend to request its 
publication in one week.

http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-07.txt

Thanks,

Gonzalo
HIP co-chair

---

From: Tobias Heer <[email-masked]>
Date: Wed, 22 Jul 2009 17:20:47 +0300

Hi everyone.

Below some comments on the draft. I am sorry that these comments are  
so late but I hope they are useful anyway.

Conceptual comments first:
---------------------------

Section 4.1: The behavior of the system if HIP_ENDPOINT_ANY is used is  
not clear. First, the text says that "any other type of address" can  
be returned. I would like to know which addresses this could be. After  
talking to Miika he confirmed that "any other address" means IPv4 or  
IPv6. It would be good to be clear here.

The possibility of ending up with an IPv4 socket when using  
HIP_ENDPOINT_ANY also bears a follow-up problem: Since the address  
format of IPv4 and IPv6 differ, it is not clear what sockaddr_hip  
should contain if the socket is bound to an IPv4 address instead a HIT  
or IPv6 address. From the text it is not clear if a sockaddr_hip would  
be replied at all or if a sockadr_in or sockadr_in6 would be replied.  
After some private discussion with Miika we came up with the following  
solution: In the IPv6 case sockaddr_hip.hip_hit_t should contain a  
regular IPv6 address (no magic because these have the same format as  
HITs). In the IPv4 case, the sockaddr_hip.hip_hit_t should be a mapped  
representation of the IPv4 address in IPv6 format (see RFC2553). In  
case the system calls accept() or recv() return a sockaddr_hip after  
binding to HIP_ENDPOINT_ANY, the host should check the type of the  
address with the sockaddr_is_srcaddr function to determine the actual  
nature of the socket. I suggest to clarify this issue in Section 4.1.

Section 4.3: The text only considers the HIP_HIT_* wildcards but not  
the HIP_ENDPOINT_ANY wildcard. Explanation about the possible bindings  
for HIP_ENDPOINT_ANY (IPv4, IPv6, HIT) should be given here, too. The  
function getsockname() and getpeername() could also return a mapped  
IPv4 address of a IPv6 address in case the socket is not HIP. Again  
the use of sockaddr_is_srcaddr should be considered to figure out the  
type of socket.

Security considerations: The use of HIP_ENDPOINT_ANY and a resulting  
binding to an IPv4 or IPv6 socket leads to a lower level of security  
compared to HIP. In my opinion this should be noted in the security  
considerations.

Editorial comments:
--------------------

Section 3: I suggest to rename Section 3 ("API Overview") to something  
like "Name Resolution Process" or "Resolver Overview" because it does  
only talk about the resolver and not about the API in general.

Section 3.1: There should be a reference to Figure 1 in the beginning  
of Section 3.1.

Section 4.1: The text says that the system should return -1 and  
EAFNOSUPPORT if AF_HIP is not supported. I suggest to emphasize that  
this is the default behavior for unsupported address families and that  
this does not require changes to legacy hosts.

Section 4.2.1: "Resolver can return" -> "The resolver can return"

Section 4.3: The text is somewhat confusing because first the client  
case and then the server case are explained without notable  
distinction. I suggest to only talk about the server case here since  
this is not relevant for the client anyway.

Section 4.4: The section talks about specific bindings to certain HIP  
classes. Noting that a binding to specific HIT can also be achieved by  
using bind() and a local HIT in sockaddr_hip.hip_hit_t may be helpful.

Best regards!

Tobias

Am 20.07.2009 um 13:27 schrieb Gonzalo Camarillo:

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

--  

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: Ari Keranen <[email-masked]>
Date: Wed, 29 Jul 2009 16:02:32 +0300

Hi,

Sorry that this comes a bit late in the process, but I think it would 
make sense to have support for the source routing & route recording 
ROUTE_DST and ROUTE_VIA parameters [1] in the HIP native API. They are 
needed for HIP BONE but likely they have use also in other contexts and 
then an application would need an API for using them.

Maybe the API that RFC 2292 [2] defines for IPv6 routing header could be 
re-used for this purpose.

Cheers,
Ari

[1] http://tools.ietf.org/html/draft-camarillo-hip-via-00
[2] http://tools.ietf.org/html/rfc2292#section-8

---

From: Miika Komu <[email-masked]>
Date: Wed, 29 Jul 2009 18:24:47 +0300

Tobias Heer wrote:

Hi,

thanks for Tobias for good comments! A new preversion updated with the 
comments from Tobias is here:

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

I'll submit the final version today after Tobias has acknowledged the 
changes and I've written text for Ari's overlay extensions.

Below some replies for the comments from Tobias.

> Hi everyone.
> 
> Below some comments on the draft. I am sorry that these comments are so 
> late but I hope they are useful anyway.
> 
> not clear. First, the text says that "any other type of address" can be 
> returned. I would like to know which addresses this could be. After 
> format of IPv4 and IPv6 differ, it is not clear what sockaddr_hip should 
> contain if the socket is bound to an IPv4 address instead a HIT or IPv6 
> address. From the text it is not clear if a sockaddr_hip would be 
> replied at all or if a sockadr_in or sockadr_in6 would be replied. After 
> some private discussion with Miika we came up with the following 
> representation of the IPv4 address in IPv6 format (see RFC2553). In case 
> the system calls accept() or recv() return a sockaddr_hip after binding 
> to HIP_ENDPOINT_ANY, the host should check the type of the address with 
> the sockaddr_is_srcaddr function to determine the actual nature of the 
> socket. I suggest to clarify this issue in Section 4.1.

Added one paragraph:

    When a connection-oriented server application binds to
    HIP_ENDPOINT_ANY and calls accept(), the call outputs always a
    sockaddr_hip structure containing information on the connected client
    with the address family set to AF_HIP.  The same applies also to
    datagram-oriented recvfrom() and recvmsg() calls.  If the data flow
    was based on HIP, the ship_hit field contains a HIT.  In the case of
    an IPv6 data flow without HIP, the field contains the corresponding
    IPv6 address of the client.  In the case of an IPv4 flow without HIP,
    the fields contains the client's IPv4 address in IPv4-mapped IPv6
    address format as described in section 3.7 of [RFC2553].  Section 4.5
    describes how the application can verify the type of the address
    returned by the socket API calls.

Is this ok?

> Section 4.3: The text only considers the HIP_HIT_* wildcards but not the 
> HIP_ENDPOINT_ANY wildcard. Explanation about the possible bindings for 
> HIP_ENDPOINT_ANY (IPv4, IPv6, HIT) should be given here, too. The 
> function getsockname() and getpeername() could also return a mapped IPv4 
> address of a IPv6 address in case the socket is not HIP. Again the use 
> of sockaddr_is_srcaddr should be considered to figure out the type of 
> socket.

I did the following two changes:

    However, the sockaddr_hip structure does not contain a HIT when the
    application uses the HIP_HIT_ANY_* or HIP_ENDPOINT_ANY constants..

    ..The application should be prepared to handle also IPv4 and IPv6
    addresses in the ship_hit field as described in Section 4.1 in the
    context of the HIP_ENDPOINT_ANY constant.

> compared to HIP. In my opinion this should be noted in the security 

Added:

    The use of HIP_ENDPOINT_ANY can be used to accept incoming or create
    outgoing data flows without HIP.  The application should use the
    sockaddr_is_srcaddr() function to validate the type of the connection
    in order to e.g. inform the user of the lack of HIP-based security.
    The use of the HIP_HIT_ANY_* constants is recommended in security-
    critical applications and systems.

> Editorial comments:

Done.

> Section 3.1: There should be a reference to Figure 1 in the beginning of 
> Section 3.1.

It was already there on the first paragraph, second sentence:

    Before an application can establish network communications with the
    entity named by a given FQDN or relative host name, the application
    must translate the name into the corresponding identifier(s).  DNS-
    based hostname-to-identifier translation is illustrated in Figure 1.

> this does not require changes to legacy hosts.

Added:

   This is the default behavior for unsupported address families
   and does not require any changes to legacy systems.

> Section 4.2.1: "Resolver can return" -> "The resolver can return"

Ok.

> case and then the server case are explained without notable distinction. 
> I suggest to only talk about the server case here since this is not 
> relevant for the client anyway.

But it is relevant to clients as well. Earlier section says:

   The use of HIP_ENDPOINT_ANY constant in the context of outgoing
   communications is left for further experimentation in the context
   of opportunistic mode. It can result in a data flow with or
   without HIP.

I believe that it was the first sentence that was confusing you, so I 
just removed it from the text. Is it ok now?

> using bind() and a local HIT in sockaddr_hip.hip_hit_t may be helpful.

I added an introduction to the beginning of the section:

    A client-side application can choose its source HIT by e.g. querying
    all of the local HITs with getaddrinfo() and associating one of them
    with the socket using bind().  This section describes another method
    for a client-side application to affect the selection of the source
    HIT type where the application does not call bind() explicitly.
    Instead, the application just specifies the preferred requirements
    for the source HIT type.

---

From: Miika Komu <[email-masked]>
Date: Wed, 29 Jul 2009 19:04:24 +0300

Ari Keranen wrote:

Hi,

> [2] http://tools.ietf.org/html/rfc2292#section-8

I had a brief look a the routing header options and I think this would 
require a lot more work. I think we just can't tell "use IPv6 routing 
header for route recording" because we need to dig out the differences 
with orchid vs. IPv6 routing and flesh out all the details. The current 
time schedule is quite tight for this too.

Currently, the native API draft defines "Basic Socket Interface 
Extensions for Host Identity Protocol (HIP)". I believe the hiccups 
extensions belong to the category of "advanced" and the reference to [2] 
is also "Advanced Sockets API for IPv6".

I would propose that we'd introduce another document for orchid routing 
or add them to the VIA draft. Please comment this proposal ASAP so that 
I'll have more time to hack this over the night if people want to see 
the changes in the native API.

---

From: Miika Komu <[email-masked]>
Date: Wed, 29 Jul 2009 19:20:18 +0300

Miika Komu wrote:

Hi,

I run the draft through spell checker and made some typo fixes. If 
nobody objects, I think the use of AI_EXTFLAGS is not strictly speaking 
necessary. Pre2 version is here:

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

---

From: Ari KerÃ¤nen <[email-masked]>
Date: Thu, 30 Jul 2009 00:13:26 +0300 (EEST)

On Wed, 29 Jul 2009, Miika Komu wrote:
> Ari Keranen wrote:
>> Sorry that this comes a bit late in the process, but I think it would make 
>> sense to have support for the source routing & route recording ROUTE_DST 
>> and ROUTE_VIA parameters [1] in the HIP native API. They are needed for HIP 
>> BONE but likely they have use also in other contexts and then an 
>> application would need an API for using them.
>> 
> require a lot more work. I think we just can't tell "use IPv6 routing header 
> for route recording" because we need to dig out the differences with orchid 
> vs. IPv6 routing and flesh out all the details. The current time schedule is 
> quite tight for this too.
>

Actually my idea was not that you would use IPv6 routing header for the 
route recording, but you could perhaps re-use the API -- if it makes 
sense. The actual (HIP) route recording and source routing would be done 
with the ROUTE_{VIA,DST} parameters. If some other API than what RFC 2292 
proposes is better, that's perfectly fine for me. Based on your comments, 
some other form of API is probably better.

Essentially an application would need to be able to give a HIP socket a 
list of HITs (for source routing), set option to enable route recording 
and symmetric routing, and be able to read a recorded route (i.e., a list 
of HITs). I think a quite simple API extension would be sufficient for 
this.

But by tight schedule are you referring to WGLC? I guess it's OK to 
postpone that a couple of days/weeks, if necessary?

> Currently, the native API draft defines "Basic Socket Interface Extensions 
> for Host Identity Protocol (HIP)". I believe the hiccups extensions belong to 
> the category of "advanced" and the reference to [2] is also "Advanced Sockets 
> API for IPv6".
>
> I would propose that we'd introduce another document for orchid routing or 
> add them to the VIA draft. Please comment this proposal ASAP so that I'll 
> have more time to hack this over the night if people want to see the changes 
> in the native API.
>

This is not really a HICCUPS extension, but I see your point. If we have 
more "advanced" features, a new API draft could make sense, but probably 
not for just this extension. Also the VIA draft does not seem like a right 
place for API documentation.

Cheers,
Ari

---

From: Tobias Heer <[email-masked]>
Date: Wed, 29 Jul 2009 23:13:59 +0200

Hi Miika,

I am fine with all changes. Below I acknowledged them one by one but I  
do not have any objections.

BR,

Tobias

Am 29.07.2009 um 17:24 schrieb Miika Komu:

> Tobias Heer wrote:
>
> Hi,
>
> thanks for Tobias for good comments! A new preversion updated with  
> the comments from Tobias is here:
>
> I'll submit the final version today after Tobias has acknowledged  
> the changes and I've written text for Ari's overlay extensions.
>
>> Below some comments on the draft. I am sorry that these comments  
>> are so late but I hope they are useful anyway.
>> Section 4.1: The behavior of the system if HIP_ENDPOINT_ANY is used  
>> is not clear. First, the text says that "any other type of address"  
>> can be returned. I would like to know which addresses this could  
>> be. After talking to Miika he confirmed that "any other address"  
>> means IPv4 or IPv6. It would be good to be clear here.
>> should contain if the socket is bound to an IPv4 address instead a  
>> HIT or IPv6 address. From the text it is not clear if a  
>> sockaddr_hip would be replied at all or if a sockadr_in or  
>> sockadr_in6 would be replied. After some private discussion with  
>> Miika we came up with the following solution: In the IPv6 case  
>> sockaddr_hip.hip_hit_t should contain a regular IPv6 address (no  
>> magic because these have the same format as HITs). In the IPv4  
>> case, the sockaddr_hip.hip_hit_t should be a mapped representation  
>> of the IPv4 address in IPv6 format (see RFC2553). In case the  
>> system calls accept() or recv() return a sockaddr_hip after binding  
>> to HIP_ENDPOINT_ANY, the host should check the type of the address  
>> with the sockaddr_is_srcaddr function to determine the actual  

Yes.

>
>> Section 4.3: The text only considers the HIP_HIT_* wildcards but  
>> not the HIP_ENDPOINT_ANY wildcard. Explanation about the possible  
>> bindings for HIP_ENDPOINT_ANY (IPv4, IPv6, HIT) should be given  
>> here, too. The function getsockname() and getpeername() could also  
>> return a mapped IPv4 address of a IPv6 address in case the socket  
>> is not HIP. Again the use of sockaddr_is_srcaddr should be  
>> considered to figure out the type of socket.
>

Good, thanks.

>
>> Security considerations: The use of HIP_ENDPOINT_ANY and a  
>> resulting binding to an IPv4 or IPv6 socket leads to a lower level  
>> of security compared to HIP. In my opinion this should be noted in  
>> the security considerations.
>
> Added:
>

okay.

>
>> Editorial comments:
>> --------------------
>> Section 3: I suggest to rename Section 3 ("API Overview") to  
>> something like "Name Resolution Process" or "Resolver Overview"  
>> because it does only talk about the resolver and not about the API  
>> in general.
>
> Done.

ok.
>
>> Section 3.1: There should be a reference to Figure 1 in the  
>> beginning of Section 3.1.
>
>> EAFNOSUPPORT if AF_HIP is not supported. I suggest to emphasize  
>> that this is the default behavior for unsupported address families  
>> and that this does not require changes to legacy hosts.
>
> Added:
>

Ok.
>
>> Section 4.3: The text is somewhat confusing because first the  
>> client case and then the server case are explained without notable  
>> distinction. I suggest to only talk about the server case here  
>> since this is not relevant for the client anyway.
>
> I believe that it was the first sentence that was confusing you, so  
> I just removed it from the text. Is it ok now?
>

Ok.

>> Section 4.4: The section talks about specific bindings to certain  
>> HIP classes. Noting that a binding to specific HIT can also be  
>> achieved by using bind() and a local HIT in sockaddr_hip.hip_hit_t  
>> may be helpful.
>

Okay.

>>> the draft below includes all the comments received during its  
>>> WGLC. Please, have a final look at it because we intend to request  
>>> its publication in one week.
>>>

--

---

From: Miika Komu <[email-masked]>
Date: Thu, 30 Jul 2009 00:28:14 +0300

Tobias Heer wrote:

Hi,

thanks, you changes are available now in the final 08 version.

>>> can be returned. I would like to know which addresses this could be. 
>>> After talking to Miika he confirmed that "any other address" means 
>>> IPv4 or IPv6. It would be good to be clear here.
>>> HIT or IPv6 address. From the text it is not clear if a sockaddr_hip 
>>> would be replied at all or if a sockadr_in or sockadr_in6 would be 
>>> replied. After some private discussion with Miika we came up with the 
>>> following solution: In the IPv6 case sockaddr_hip.hip_hit_t should 
>>> contain a regular IPv6 address (no magic because these have the same 
>>> format as HITs). In the IPv4 case, the sockaddr_hip.hip_hit_t should 
>>> be a mapped representation of the IPv4 address in IPv6 format (see 
>>> RFC2553). In case the system calls accept() or recv() return a 
>>> sockaddr_hip after binding to HIP_ENDPOINT_ANY, the host should check 
>>> the type of the address with the sockaddr_is_srcaddr function to 
>>> determine the actual nature of the socket. I suggest to clarify this 
>>> issue in Section 4.1.
>>
>> Added one paragraph:
>>
>>> the HIP_ENDPOINT_ANY wildcard. Explanation about the possible 
>>> bindings for HIP_ENDPOINT_ANY (IPv4, IPv6, HIT) should be given here, 
>>> too. The function getsockname() and getpeername() could also return a 
>>> mapped IPv4 address of a IPv6 address in case the socket is not HIP. 
>>> Again the use of sockaddr_is_srcaddr should be considered to figure 
>>> out the type of socket.
>>
>>> because it does only talk about the resolver and not about the API in 
>>> general.
>>
>> Done.
> 
> ok.
>>
>>> this is the default behavior for unsupported address families and 
>>> that this does not require changes to legacy hosts.
>>
>> Added:
>>
>>> classes. Noting that a binding to specific HIT can also be achieved 
>>> by using bind() and a local HIT in sockaddr_hip.hip_hit_t may be 
>>> helpful.
>>

---

From: Miika Komu <[email-masked]>
Date: Thu, 30 Jul 2009 00:59:00 +0300

Ari Keränen wrote:

Hi,

>>> ROUTE_DST and ROUTE_VIA parameters [1] in the HIP native API. They 
>>> are needed for HIP BONE but likely they have use also in other 
>>> contexts and then an application would need an API for using them.
>>>
>>> Maybe the API that RFC 2292 [2] defines for IPv6 routing header could 
>>> be re-used for this purpose.
>>>
>>>
>>> Cheers,
>>> Ari
>>>
>> with orchid vs. IPv6 routing and flesh out all the details. The 
>> current time schedule is quite tight for this too.
>>
> 
> with the ROUTE_{VIA,DST} parameters. If some other API than what RFC 
> 2292 proposes is better, that's perfectly fine for me. Based on your 
> comments, some other form of API is probably better.

I didn't mean that RFC2292 is not suitable. I merely questioned where 
this functionality should be added and that we shouldn't be hasty in 
adding new features that haven't been properly chewed first.

We'd probably need also some socket options to turn hiccups on and off. 
All of the requirements are not clear to me yet.

> and symmetric routing, and be able to read a recorded route (i.e., a 
> list of HITs). I think a quite simple API extension would be sufficient 
> for this.
> 

Any other opinions on this? What should we do about it?

I have submitted the final 08 version. I am fine with delaying if people 
feel that source routing should be included, but I think it could also 
be hosted in a different draft.

>> extensions belong to the category of "advanced" and the reference to 
>> [2] is also "Advanced Sockets API for IPv6".
>>
>> I would propose that we'd introduce another document for orchid 
>> routing or add them to the VIA draft. Please comment this proposal 
>> ASAP so that I'll have more time to hack this over the night if people 
>> want to see the changes in the native API.
>>
> 
> not for just this extension. Also the VIA draft does not seem like a 
> right place for API documentation.

We left out RFC3484 related issues from the native API draft because it 
was too immature for last call. If we started up a new draft, we could 
include source HIT selection when a host has multiple HITs.

---

From: Ari Keranen <[email-masked]>
Date: Thu, 30 Jul 2009 13:48:03 +0300

Miika Komu wrote:
>>>> Sorry that this comes a bit late in the process, but I think it 
>>>> would make sense to have support for the source routing & route 
>>>> recording ROUTE_DST and ROUTE_VIA parameters [1] in the HIP native 
>>>> API. They are needed for HIP BONE but likely they have use also in 
>>>> other contexts and then an application would need an API for using 
>>>> them.
>>>>
>>>> Maybe the API that RFC 2292 [2] defines for IPv6 routing header 
>>>> could be re-used for this purpose.
>>>>
>>>>
>>>> Cheers,
>>>> Ari
>>>>
>>> I had a brief look a the routing header options and I think this 
>>> would require a lot more work. I think we just can't tell "use IPv6 
>>> routing header for route recording" because we need to dig out the 
>>> differences with orchid vs. IPv6 routing and flesh out all the 
>>> details. The current time schedule is quite tight for this too.
>>>
>>
>> Actually my idea was not that you would use IPv6 routing header for 
>> the route recording, but you could perhaps re-use the API -- if it 
>> makes sense. The actual (HIP) route recording and source routing would 
>> be done with the ROUTE_{VIA,DST} parameters. If some other API than 
>> what RFC 2292 proposes is better, that's perfectly fine for me. Based 
>> on your comments, some other form of API is probably better.
> 

OK.

> All of the requirements are not clear to me yet.

Yes, some HICCUPS API extensions would be useful too.

>> Essentially an application would need to be able to give a HIP socket 
>> a list of HITs (for source routing), set option to enable route 
>> recording and symmetric routing, and be able to read a recorded route 
>> (i.e., a list of HITs). I think a quite simple API extension would be 
>> sufficient for this.
>>

OK (more of this below).

>>> ASAP so that I'll have more time to hack this over the night if 
>>> people want to see the changes in the native API.
>>>
>>
>> This is not really a HICCUPS extension, but I see your point. If we 
>> have more "advanced" features, a new API draft could make sense, but 
>> probably not for just this extension. Also the VIA draft does not seem 
>> like a right place for API documentation.
> 

OK, so maybe there is need for such advanced API draft after all and the 
VIA extensions, as well as HICCUPS extensions, would fit there well. So, 
I guess there is no need to delay the WGLC of the current basic API draft.

Cheers,
Ari