Subject: [Hipsec] feedback of hiccups-01 draft

From: Miika Komu <[email-masked]>
Date: Thu, 29 Jan 2009 09:49:18 +0200

Hi,

I have some feedback of the hiccups draft. The draft is well written and 
easy to read and understand. However, I have few questions (sorry if 
these have been asked already):

* I guess the draft assumes that data packets may be sent over HIP-aware 
overlays. I would suggest that the authors have a look at 
draft-heer-hip-middle-auth and perhaps add a pointer to the draft. 
Particularly, I would propose to make the public key mandatory and 
perhaps the middlebox extension as SHOULD? There is a new version of the 
draft coming up very soon. Feel free to ask Tobias for a preview if you 
are interested.

* The justification for the seq/ack mechanism is a bit unclear. Is it 
only about replay protection?

* I just implemented minimal support for HIP_DATA in HIPL. Now the 
implementation should be able to respond with an R1 to a HIPL_DATA 
packet. Now we need to test it for interoperability :) I would suggest 
that OpenHIP folks also implemented this feature because it should be 
only few lines of code.

* Second paragraph in section 5 explain about the issues with 
fragmentation. Implementation wise, shouldn't this problem be just 
solved by lowering the MTU of the tunnel device by the size of HIP 
header, [HOST_ID], payload HMAC and HIP_SIGNATURE?
_______________________________________________
Hipsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hipsec

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 30 Jan 2009 10:24:42 -0800

> only about replay protection?

I have a similar question-- why not just make this an unreliable data
service and delegate reliability to the application?

> that OpenHIP folks also implemented this feature because it should be 

what is your user-space API for this service?  It is some kind of
SEQPACKET socket?

> header, [HOST_ID], payload HMAC and HIP_SIGNATURE?

I think this is a complicated issue and agree that it would be helpful
to give more guidance on how to handle it, beyond "should not generate
too large datagrams".  Again, there may be API issues to discuss with
respect to this.

- Tom