Subject: [Hipsec] Draft: data transport in HIP

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jul 2008 16:06:59 +0300

Folks,

we have just submitted the following draft:

http://www.ietf.org/internet-drafts/draft-nikander-hip-hiccups-00.txt

It relates to the following item in our charter:

o Specify how to carry upper-layer data over specified HIP
packets. These include some of the existing HIP packets and possibly
new HIP packets (e.g., a HIP packet that occurs outside a HIP base
exchange).

The draft includes discussions about when it is appropriate to use such 
a mechanism and some of the trade offs involved. Once we have more 
discussions on this topic, we will need to fill in more details, 
especially on the interactions with overlays. We hope to receive 
comments on the list.

Thanks,

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 31 Jul 2008 08:51:26 -0700

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Wednesday, July 30, 2008 6:07 AM
> To: HIP
> Cc: Pekka Nikander (JO/LMF); Jan Melen
> Subject: [Hipsec] Draft: data transport in HIP
> 
> Folks,
> 

Gonzalo, Pekka, and Jan,

I think the draft is a nice overview of the issues and possibilities of
extending HIP, but it stops short of discussing what the API might look
like, which in my opinion is going to be the hard part of this effort.

I was thinking that, to complete the charter item, we will need a
document that might be entitled something like "HIP as a service."  This
document would specify an API (like a library) that signaling protocols
could write to.  Then, depending on the API we want to offer, we might
need to extend HIP.  If we want to go in that direction, then the next
step might be to discuss what should the API look like.  

Regards,
Tom

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 31 Jul 2008 19:16:47 +0300

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.

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.

Thanks for the comments,

Gonzalo

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 31 Jul 2008 10:26:08 -0700

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

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.

> 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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 31 Jul 2008 20:32:53 +0300

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 31 Jul 2008 10:42:31 -0700

> Sent: Thursday, July 31, 2008 10:33 AM
> To: Henderson, Thomas R

Currently, the HIP native API draft is not scoped to include providing a
signaling carriage service; it is oriented towards providing traditional
ESP service.

Would you like the scope of draft-ietf-hip-native-api expanded, then?

Tom

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 31 Jul 2008 20:48:55 +0300

Hi,

> Would you like the scope of draft-ietf-hip-native-api expanded, then?

That was my assumption, but if people think that having two different 
documents would be a clearer solution, that would work for me as well. 
It would be great to hear more opinions on this.

Cheers,

Gonzalo