Subject: [Hipsec] Re: some questions regarding the update packet protocol

From: [email-masked] (Pekka Nikander)
Date: Wed Apr 6 01:55:00 2005

Greg,

[CC:n to the list as I think this belongs to the WG and
raises important topics.]

>> UPDATEs MAY be retransmitting without incrementing SEQ.  ...
>
> How to process equal sequence numbers due (normally) to 
> retransmissions is
> outlined in section 8.10.1.  But what is the difference between
> retransmission and a replay attack?  Nothing as far as I can tell?

IIRC, the intention is to say that as packets may get duplicated in
the IP network anyway, also the sending host may send duplicate packets.
For example, if the sender does not receive a corresponding ACK, it
may resend an old, already signed packet instead of constructing a new
packet and signing that.

 From the receiver's perspective, it is no different from receiving
a recent packet multiple times.  The receiver does not know if the
packet has been duplicated in the net, is a replay attack attempt,
or has been resent by the sender.

Maybe the text needs to be clarified?

>
>> If the same
>>   subset of parameters is included in multiple UPDATEs with different
>>   SEQs, the host MUST ensure that receiver processing of the 
>> parameters
>>   multiple times will not result in a protocol error.
>
> I also don't understand that.  Is that saying you have received the 
> same HIP
> update packet with only the SEQ changed?  So I can resend the same 
> update
> packet with an incremented SEQ, yes?

IIRC, the intention is just to clarify the semantics.  For example,
let say that we have a hypothetical payload "Increment a counter by 
one".
Now, if you send two identical UPDATEs with the *same* SEQ, both 
containing
the "increment a counter by one", the counter will be incremented once.
However, if you send two UPDATEs with *different* SEQs but otherwise
identical, the counter will be incremented twice.

This is probably too obvious, and hence some text clarification might
be needed.  Suggestions?

Or maybe we should write more text about the perhaps-obvious semantics
issue that the sender must not assume anything about the receiver's
state beyond acked UPDATEs.  That is, if the sender has several pending
updates out, the protocol must work correctly independent on which of 
the
pending updates actually reach the receiver and in which order.

> From the way update packets are processed and tracked, it seems that 
> clients
> could easily bombard a service with HIP update packets that the client 
> only
> created once but can resend many times.  Of course, this can be done 
> already
> in toiday's Internet but with HIP, if the signature is being checked, 
> this
> will cause greater problems.

One way to counter that is to remember some past received UPDATEs and
any responses to them, and simply re-send the already existing response
in the case of receiving a resent UPDATE.

>  I think their needs to be an update counter
> that gets incremented with each update and decremented over time.  
> Once you
> reach some threshold MAX_UPDATE_COUNT the receiver starts to send
> challenges, maybe pre-made encrypted nonces for the update initiator to
> decrypt, where the nonce must be sent back before any further update 
> packets
> are processed.  This is just an extension of the puzzle challenge idea 
> in
> the base exchange onto the update packet protocol (make the initiator 
> do
> some work).  I think something like this would help since the HIP 
> exchange
> is good against most attacks while the update packet protocol seems
> vulnerable.

In principle, sounds like a good idea under certain circumstances,
especially when an non-trusted (perhaps anonymous) peer sends updates
in a rapid rate, and especially if any of the signatures fails.
However, before proceeding with writing any text, I think we need
to better understand the pros and cons.  Simply allowing either of
the peers to pose a challenge to the other saying "If you want to
continue please solve this puzzle" may not be a good idea, as that
also may be used as a DoS tool.

--Pekka

---

From: [email-masked] (Greg Perkins)
Date: Thu Apr 7 14:41:00 2005

Thanks for your responses Pekka, making update packets less useful to
attackers is going to be a little more complex than I thought.

> may resend an old, already signed packet instead of constructing a new
Ok, fair enough.

> pending updates actually reach the receiver and in which order.
Ok, I think I get this now.  I think the protocol should not send another,
different update packet until a current outstanding update packet is acked
by the receiver (or the protocol drops it, like if a mobile node sends a
update packet but then gets a new ip address before receiving an ACK it can
reset state and send a new update packet).  This would simplify analysis of
the interactions of the two HIP host's state machines.  Would that cause any
problems (I have trouble think of cases where I would want to send multiple
update packets since I can bundle multiple requests into a single update
packet)?  Now If the receiving host is processing an update packet and
receives a new one it too would need to reset state and then process the new
update packet.  A problem can occur if the receiver processes an update
packet, ACKs it and changes state yet the sender has reset state and sent a
new update packet before receiving the ACK.  A way to fix that is that
update packets have their own counters.  Even after processing and sending
an ACK the receiver will still reset state if it receives a new update
packet with the same update packet counter (sequence number basically).  An
update packet sequence number only gets incremented after an ACK has been
received.  I think this would help keep the HIP protocol running smoothly.

> in the case of receiving a resent UPDATE.
I thought about that previously and decided that an attacker would simply
create more instances of update packets than an implementation would save,
then cycle through them.  There is just no way to stop this without
implementing an intrusion detection system at the IP layer (that seems
unlikely ;) ) or limiting the number of requests in order to limit the
damage that an attacker can do.  Some limit based on RTT might help here but
could cause problems with fast moving mobile hosts (or host's on connection
boundaries).  So probably allow REA update packets at anytime but if the
same update packet or a different update packet is received before RTT then
drop it or even flag it as an attack and drop the connection.  That would at
least help.

> also may be used as a DoS tool.
Good point.  I made an assumption that I never stated which is that an
initiator of a HIP session can never send a challenge.  If the receiver of a
HIP I1 ever receives a challenge they can elect to drop the session.

This is good, I think something simple yet helpful can be done here with
only a little bit of extra state being saved.  Attacks will be possible but
I think they can be limited.

Greg

----- Original Message ----- 
From: "Pekka Nikander" <[email-masked]>
To: "Greg Perkins" <[email-masked]>
Cc: <[email-masked]>; "Christian Vogt" <[email-masked]>;
"Ahrenholz, Jeffrey M" <[email-masked]>; "Jari Arkko"
<[email-masked]>; "Jan Mikael Melen" <[email-masked]>;
"Thomas R Henderson" <[email-masked]>
Sent: Wednesday, April 06, 2005 1:54 AM
Subject: [Hipsec] Re: some questions regarding the update packet protocol

> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>