Subject: Re: [Hipsec] feedback of hiccups-01 draft

From: Jan Melen <[email-masked]>
Date: Tue, 28 Jul 2009 17:34:41 +0300

Hi,

Henderson, Thomas R wrote:
>> * The justification for the seq/ack mechanism is a bit unclear. Is it 
>> only about replay protection?
>>     
>
> I have a similar question-- why not just make this an unreliable data
> service and delegate reliability to the application?
>
>   

The justification is in the main user of the HIP_DATA packet which is 
the a signalling application. The HIP_DATA packet is meant only for 
exchanging few packets between the hosts not a stream of data. If you 
need to exchange a large stream of data then you should run base 
exchange and not use HIP_DATA.

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

I will add some more text in that section

Jan

---

From: Jan Melen <[email-masked]>
Date: Tue, 28 Jul 2009 17:37:37 +0300

Miika Komu wrote:
>
> * 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.

I think that the host on the path should not verify the signatures on 
HIP_DATA packets as it is meant that these are anyway only few packets 
that are exchanged between the peer's and not a stream of data. For 
streams you set-up a full HIP association using base-exchange and ESP as 
a transport.

   Jan

---

From: Miika Komu <[email-masked]>
Date: Thu, 30 Jul 2009 11:57:05 +0300

Jan Melen wrote:

Hi,

> streams you set-up a full HIP association using base-exchange and ESP as 

no, I meant that the middleboxes should apply nonces to the messages.

---

From: Tobias Heer <[email-masked]>
Date: Thu, 30 Jul 2009 11:13:00 +0200

Am 30.07.2009 um 10:57 schrieb Miika Komu:

> Jan Melen wrote:
>
> Hi,
>
>> Miika Komu wrote:
>>>
>>> * 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  
>>> 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.
>> I think that the host on the path should not verify the signatures  
>> on HIP_DATA packets as it is meant that these are anyway only few  
>> packets that are exchanged between the peer's and not a stream of  
>> data. For streams you set-up a full HIP association using base- 
>> exchange and ESP as a transport.
>

Jan is right: Without a multi-packet protocol defined (back and forth  
at least), the MB authentication extensions don't work. However, for  
packets that require an acknowledgement, it would somewhat work and  
you could determine the identity of the receiver. For authenticating  
the sender, you need three consecutive messages. Hence, using the MB  
authentication extension makes more sense for stream-like connections.

Tobias

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

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer