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

[Miika Komu <[e-mail]>]

Tobias Heer wrote:

Hi,

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

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