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

[Tobias Heer <[e-mail]>]

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:
>
> 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.
>> 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.
>
> 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?

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.
>
> 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.

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:
>
>   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.

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.
>
> 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.
>
>> 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.
>
> Added:
>
>  This is the default behavior for unsupported address families
>  and does not require any changes to legacy systems.

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.
>
> 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?
>

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.
>
> 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.

Okay.




>
>> Best regards!
>> Tobias
>> Am 20.07.2009 um 13:27 schrieb Gonzalo Camarillo:
>>> 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
>>>
>>> _______________________________________________
>>> Hipsec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/hipsec
>> -- 
>> Dipl.-Inform. Tobias Heer, Ph.D. Student
>> Distributed Systems Group
>> RWTH Aachen University, Germany
>> tel: [phone]
>> web: http://ds.cs.rwth-aachen.de/members/heer
>




--  

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