Re: [Hipsec] Draft: data transport in HIP

[Gonzalo Camarillo <[e-mail]>]

Hi,

in my view, all the non-API-related stuff you propose, belongs to this 
draft. All the API-related stuff belongs somewhere else (i.e., in the 
HIP API draft).

Cheers,

Gonzalo

Henderson, Thomas R wrote:
>  
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:[e-mail]] 
>> Sent: Thursday, July 31, 2008 9:17 AM
>> To: Henderson, Thomas R
>> Cc: HIP; Pekka Nikander (JO/LMF); Jan Melen
>> Subject: Re: [Hipsec] Draft: data transport in HIP
>>
>> Hi Tom,
>>
>> the idea with this draft is the following:
>>
>> o define a HIP DATA packet as discussed in the past.
>> o discuss the trade offs involved in the use of this packet. We gain 
>> efficiency but lose DoS protection.
>> o discuss under which circumstances implementations may want 
>> to use DATA 
>> and also under which circumstances an implementation wants to 
>> accept or 
>> reject DATA (e.g., in some cases, an application that is part of a 
>> trusted overlay may want to accept DATA).
>> o when an implementation does not want to accept DATA (e.g., 
>> because of 
>> DoS concerns), it needs to be able to return an R1 to start a base 
>> exchange instead.
>>
>>
>> The reason why, at this point, the document does not spend 
>> time defining 
>>   DATA is because we wanted to stress the importance of the 
>> discussions 
>> on why it is appropriate to use such a mechanism. We will be 
>> introducing 
>> the definition of DATA in future revisions of the draft.
> 
> I wasn't suggesting to spend time defining DATA now, but to define how
> the user of DATA perceives the service that DATA provides.
> 
> The HICCUPS draft briefly states what is the purpose of this service--
> to provide carriage of signaling messages between hosts, while solving
> for the signaling protocol all of the details of NAT traversal,
> mobility, multihoming.  This, to me, would be clearly a nice service to
> provide, and I don't know how much more you need to justify it.
> 
> However, there are a lot of details that need to be resolved, such as:
> - what are the delivery semantics (reliable, unreliable) of such
> messages?
> - what are the security semantics?  From a server perspective, should
> application be able to select a listening service that uses base
> exchange or not, or should that detail be hidden from the signaling
> application?  Can/should applications specify what source HIT should be
> used?  Should applications be able to provide or load their own host
> identity?  Should opportunistic mode be supported, and how is this mode
> controlled?
> - can applications use this service by providing a URL or by providing
> only a destination HIT?  
> - does the application provide hints as to which overlay the destination
> HIT has stored its bindings?
> - what kind of other policy can an application flow down to the HIP
> daemon, and how is it communicated at the API?
> - do locators (addresses) play any role at the API level?
> - what kind of error codes are provided back to the signaling
> applications?
> 
> I don't think we can fully specify DATA until we understand how the
> above questions are answered.
> 
>> With respect to the API, we decided to wait with the API 
>> draft until the 
>> NAT traversal and overlay work is in a more advanced state so that we 
>> have a clearer picture on the requirements for a HIP API.
>>
> 
> Yes, these issues (overlay, native API, HICCUPS) are all bound together,
> but I think that to move forward on the protocol details, we first have
> to have a clear vision as to what is the service API we are trying to
> support.  
> 
> Regards,
> Tom 

_______________________________________________
Hipsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hipsec