Subject: [Hipsec] Comments on hiccups draft

From: Tobias Heer <[email-masked]>
Date: Mon, 27 Jul 2009 16:26:05 +0200

Some comments on the hiccups draft. In general I find the approach  
interesting and worth pursuing. Below are some questions that mostly  
focus on security:

Conceptual comments and questions:
----------------------------------

Section 3: Existence of the HMAC in the packet:
The hiccups draft states that "[the payload is] protected by a  
PAYLOAD_HMAC parameter". To me it is unclear how such protection can  
possibly work. Since there is no previous handshake there are no keys  
for use in the HMAC. Jan explained that the HMAC is merely used as a  
way to create a digest over the packet for making the signature more  
efficient. However, if it is only used for creating the digest, I  
wonder why it is actually transmitted in the packet because without a  
secret included in the packet, the digest can easily be calculated and  
transmitting the digest in a packet seems to be a unnecessary waste of  
space. Am I missing something here? It would be nice if the draft was  
more precise about the nature and the use of the HMAC.

Section 4.3: Sending R1 if receiver suspects an attack:
I guess that in this case, the receiver drops the data packet and its  
content should be retransmitted (by a higher-layer mechanism?)? If  
yes, this could be mentioned somewhere.

Replay protection:
The draft talks about a immediate replays of DATA packets in the  
context of DoS attacks targeted at ACK signature generation. However,  
it does not talk about replays after a longer time (e.g. to mess with  
upper-layer state machines).
How can hosts shelter against replays of valid but old hiccups  
packets? The sequence number only works from the second packet on and  
still complete sequences of HIP DATA packets can be replayed. Caching  
packets or keeping state for every ever-received packet is probably  
not feasible. Is there a solution? If not, this should also be stated  
in the text and the security considerations.

Various sections: DoS resistance:
The draft briefly mentions that the protocol is susceptible to DoS  
attacks. This statement is rather vague and only mentions the absence  
of "half-stateless DoS protection nature of the base exchange" and  
immediate replays. However, CPU targeted DoS attacks (verification of  
PK-sigantures without a puzzle or working HMAC to shelter against  
floods of HIP DATA packets - not necessarily replays) seem much more  
realistic to me than state a space exhaustion attacks. Using HIP DATA  
packet creates a computational asymmetry between the attacker and the  
victim (receiver). This imbalance could be mentioned in a more  
explicit way.

Editorial comments:
-------------------

Section 4.3: "The host MAY responds" -> "The host MAY respond"

Best regards,
Tobias

--  

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

---

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

Hi,

> Conceptual comments and questions:

Yes, it is only a message authentication code of the packet and I know 
that you don't have to send it but it is less prone to errors if you do 
send it as the receiving end doesn't have to generate the actual 
parameter that was used to create MAC code in order to verify the signature.

> yes, this could be mentioned somewhere.

Yes, I will add that to the draft.

> victim (receiver). This imbalance could be mentioned in a more 

These are known attacks and that is why we have said in the security 
considerations section that host should consider carefully when to 
accept HIP data packets.

> Editorial comments:

Thanks for the comments
Jan

---

From: Tobias Heer <[email-masked]>
Date: Tue, 28 Jul 2009 16:41:56 +0200

Hi Jan,

Am 28.07.2009 um 16:30 schrieb Jan Melen:

>> PAYLOAD_HMAC parameter". To me it is unclear how such protection  
>> can possibly work. Since there is no previous handshake there are  
>> no keys for use in the HMAC. Jan explained that the HMAC is merely  
>> used as a way to create a digest over the packet for making the  
>> signature more efficient. However, if it is only used for creating  
>> the digest, I wonder why it is actually transmitted in the packet  
>> because without a secret included in the packet, the digest can  
>> easily be calculated and transmitting the digest in a packet seems  
>> to be a unnecessary waste of space. Am I missing something here? It  
>> would be nice if the draft was more precise about the nature and  
>> the use of the HMAC.
>>
>
> if you do send it as the receiving end doesn't have to generate the  
> actual parameter that was used to create MAC code in order to verify  
> the signature.

You must recalculate the digest anyway. Otherwise the receiver will  
only check that the signature covers the HMAC but the receiver will  
not check that the packet contents match the HMAC. In that sense only  
the HMAC but not the packet contents would be integrity-protected.  
Since you have to generate the digest over the whole packet anew  
anyway I do not see the advantage of sending it in the packet.

Best regards,

Tobias

--

---

From: Jan Melen <[email-masked]>
Date: Tue, 28 Jul 2009 18:10:45 +0300

Hi Tobias,

Tobias Heer wrote:
>>> possibly work. Since there is no previous handshake there are no 
>>> keys for use in the HMAC. Jan explained that the HMAC is merely used 
>>> as a way to create a digest over the packet for making the signature 
>>> more efficient. However, if it is only used for creating the digest, 
>>> I wonder why it is actually transmitted in the packet because 
>>> without a secret included in the packet, the digest can easily be 
>>> calculated and transmitting the digest in a packet seems to be a 
>>> unnecessary waste of space. Am I missing something here? It would be 
>>> nice if the draft was more precise about the nature and the use of 
>>> the HMAC.
>>>
>>

Yes you have to calculate it in either case I'm not referring to that. 
I'm just saying that the implementation will be more error prone if the 
host has to calculate the digest and then create the parameter. And we 
send the parameter in the packet the receiver can already after 
calculating the digest drop packets which have been modified on the 
transmit without calculating the signature (the non-malicious errors 
that happen on transmit).

   Jan

---

From: Tobias Heer <[email-masked]>
Date: Tue, 28 Jul 2009 17:50:01 +0200

Am 28.07.2009 um 17:10 schrieb Jan Melen:

>>>> no keys for use in the HMAC. Jan explained that the HMAC is  
>>>> merely used as a way to create a digest over the packet for  
>>>> making the signature more efficient. However, if it is only used  
>>>> for creating the digest, I wonder why it is actually transmitted  
>>>> in the packet because without a secret included in the packet,  
>>>> the digest can easily be calculated and transmitting the digest  
>>>> in a packet seems to be a unnecessary waste of space. Am I  
>>>> missing something here? It would be nice if the draft was more  
>>>> precise about the nature and the use of the HMAC.
>>>>
>>>
>>> if you do send it as the receiving end doesn't have to generate  
>>> the actual parameter that was used to create MAC code in order to  
>>> verify the signature.
>>
>> not check that the packet contents match the HMAC. In that sense  
>> only the HMAC but not the packet contents would be integrity- 
>> protected. Since you have to generate the digest over the whole  
>> packet anew anyway I do not see the advantage of sending it in the  
>> packet.
>
> Yes you have to calculate it in either case I'm not referring to  
> that. I'm just saying that the implementation will be more error  
> prone if the host has to calculate the digest and then create the  
> parameter. And we send the parameter in the packet the receiver can  
> already after calculating the digest drop packets which have been  
> modified on the transmit without calculating the signature (the non- 
> malicious errors that happen on transmit).

Now everything becomes a bit clearer. Since you do not expect to have  
a UDP header (with checksum) in all cases you use the HMAC as  
checksum? That works... Although a 20-byte checksum from a  
cryptographic hash function is rather large and expensive (compared to  
the usual transport-layer checksums TCP/UDP: 2 byte). Maybe this (non- 
standard?) use of the HMAC could be stated in the draft to avoid  
confusion.

BR, Tobias

--

---

From: Jan Melen <[email-masked]>
Date: Wed, 29 Jul 2009 11:52:25 +0300

Tobias Heer wrote:
>>>>> to be a unnecessary waste of space. Am I missing something here? 
>>>>> It would be nice if the draft was more precise about the nature 
>>>>> and the use of the HMAC.
>>>>>
>>>>
>>>> actual parameter that was used to create MAC code in order to 
>>>> verify the signature.
>>>
>>> only the HMAC but not the packet contents would be 
>>> integrity-protected. Since you have to generate the digest over the 
>>> whole packet anew anyway I do not see the advantage of sending it in 
>>> the packet.
>>
>> modified on the transmit without calculating the signature (the 
>> non-malicious errors that happen on transmit).
>
> the usual transport-layer checksums TCP/UDP: 2 byte). Maybe this 
> (non-standard?) use of the HMAC could be stated in the draft to avoid 
> confusion.

The upper-layer protocol might have it's own checksum but I do not want 
to make a dependency to HIP protocol that a HIP implementation should be 
able to identify all transport protocols thus it is easier to define 
that HIP_DATA has some checksum calculation that is less expensive than 
public key signature but still provides something for the end goal. 
After all the if the packet would be IP (HIP(HIP_DATA, HIP_SIGNATURE) 
UDP ()), the processing in the stack would go in the following order:
1. IP stack processes the IP header
2. HIP processes the HIP header, HIP_DATA and HIP_SIGNATURE
3. Transport layer UDP processes the UDP header
4. Application

If we wouldn't make this check on step 2 we might do the signature 
calculation just to notice that the packet has been accidentally 
modified in transit.

But anyway I will add something to the draft.

    Jan

---

From: Jan Melen <[email-masked]>
Date: Wed, 29 Jul 2009 12:21:49 +0300

Hi Tobias,

Jan Melen wrote:
>>>> whole packet anew anyway I do not see the advantage of sending it 
>>>> in the packet.
>>>
>> cryptographic hash function is rather large and expensive (compared 
>> to the usual transport-layer checksums TCP/UDP: 2 byte). Maybe this 
> The upper-layer protocol might have it's own checksum but I do not 
> want to make a dependency to HIP protocol that a HIP implementation 
> should be able to identify all transport protocols thus it is easier 
> to define that HIP_DATA has some checksum calculation that is less 
> expensive than public key signature but still provides something for 
> the end goal. After all the if the packet would be IP (HIP(HIP_DATA, 
> HIP_SIGNATURE) UDP ()), the processing in the stack would go in the 
> following order:

http://users.piuha.net/jmelen/HICCUPS/draft-nikander-hip-hiccups-04-pre1.txt
I've now made yet another edit on the draft regarding the comment you 
gave. Take now a look at section 3 paragraph 4.

   Jan

---

From: Tobias Heer <[email-masked]>
Date: Wed, 29 Jul 2009 11:27:48 +0200

Hi Jan,

Am 29.07.2009 um 11:21 schrieb Jan Melen:

> I've now made yet another edit on the draft regarding the comment  
> you gave. Take now a look at section 3 paragraph 4.
>
I think things are clearer now. Thanks for the clarification.

Tobias

--