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

[Miika Komu <[e-mail]>]

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?

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

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

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

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

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

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?

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

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