Subject: [Hipsec] fault-tolerance for base exchange and update

From: Miika Komu <[email-masked]>
Date: Thu, 07 Jan 2010 09:22:31 +0200

Hi,

Baris Boyvat has implemented an experimental fault-tolerance extension 
for the HIP base exchange and UPDATE in the HIPL implementation. He will 
document it in his master thesis during this year, but I would like to 
start discussion of the topic already now.

At the protocol level, the extension allows sending multiple I1 or 
UPDATE-with-locator packets sequentially. The idea is to scan through 
all possible source and destination IP pairs at the HIP layer to improve 
  the chances for successful initial contact (I1) and to re-establish 
contact (UPDATE-with-locator) in way similar to the NAT-ICE extensions. 
We have playfully called the extension as "shotgun" mode in the 
implementation :)

The obvious difference to ICE is that the shotgun mode works at the HIP 
protocol layer. A non-obvious difference is that the approach supports 
also fault-tolerance for a single relay/rendezvous (Responder's RVS has 
crashed) and it can make use of multiple relay/rendezvous servers for 
better redundancy. At the moment, neither of these are possible direcly 
with the ICE-NAT extensions. I actually believe the shotgun approach can 
be applied even with the ICE-NAT extensions to improve fault-tolerance.

The shotgun approach seems useful to improve fault-tolerance with an 
without (single or multiple) rendezvous/relay middleboxes, but there is 
also another use case for this. The Initiator (or Mobile Node) can learn 
multiple mappings for the peer, some of which may have connectivity and 
some not. It is also possible that a malign user intentionally sends 
invalid mappings for a well-known service in a multiuser system (this 
case also requires some rate control for mappings per user). In such 
scenarios, it is useful to try multiple peer addresses sequentially 
instead of just single one.

Minimally, the approach requires few considerations in an implementation:

i) Allow sending of multiple I1 and UPDATE-with-locator packets in a 
rate-controlled fashion
ii) Filter redundant incoming packets.

Case (ii) could be implemented as filtering of I1 packets or filtering 
of R1 packets. We chose filtering of redundant R1 packets in the 
implementation and it required a small change in the state machine. For 
the UPDATE filtering, filtering based on sequence numbers was sufficient.

I would like the WG feedback on whether we could include this approach 
in RFC5201-bis and RFC5206-bis (as MAY or SHOULD).

P.S. Maybe Baris has something to add or to explain some details better.

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 7 Jan 2010 20:23:59 +1300

It sounds like a perfectly reasonable idea at first glance; it should work well.

And then I started thinking about congestion control and fast start, and realised that this will need specified carefully if we still believe that protocols starting very slowly is desirable to deal with low-bandwidth and congested situations.  That's likely to spark a debate, unfortunately.

Andrew

On 07/01/2010, at 8:22 PM, Miika Komu wrote:

> Hi,
> 
> Baris Boyvat has implemented an experimental fault-tolerance extension for the HIP base exchange and UPDATE in the HIPL implementation. He will document it in his master thesis during this year, but I would like to start discussion of the topic already now.
> 
> At the protocol level, the extension allows sending multiple I1 or UPDATE-with-locator packets sequentially. The idea is to scan through all possible source and destination IP pairs at the HIP layer to improve  the chances for successful initial contact (I1) and to re-establish contact (UPDATE-with-locator) in way similar to the NAT-ICE extensions. We have playfully called the extension as "shotgun" mode in the implementation :)
> 
> The obvious difference to ICE is that the shotgun mode works at the HIP protocol layer. A non-obvious difference is that the approach supports also fault-tolerance for a single relay/rendezvous (Responder's RVS has crashed) and it can make use of multiple relay/rendezvous servers for better redundancy. At the moment, neither of these are possible direcly with the ICE-NAT extensions. I actually believe the shotgun approach can be applied even with the ICE-NAT extensions to improve fault-tolerance.
> 
> The shotgun approach seems useful to improve fault-tolerance with an without (single or multiple) rendezvous/relay middleboxes, but there is also another use case for this. The Initiator (or Mobile Node) can learn multiple mappings for the peer, some of which may have connectivity and some not. It is also possible that a malign user intentionally sends invalid mappings for a well-known service in a multiuser system (this case also requires some rate control for mappings per user). In such scenarios, it is useful to try multiple peer addresses sequentially instead of just single one.
> 
> i) Allow sending of multiple I1 and UPDATE-with-locator packets in a rate-controlled fashion
> Case (ii) could be implemented as filtering of I1 packets or filtering of R1 packets. We chose filtering of redundant R1 packets in the implementation and it required a small change in the state machine. For the UPDATE filtering, filtering based on sequence numbers was sufficient.
> 
> I would like the WG feedback on whether we could include this approach in RFC5201-bis and RFC5206-bis (as MAY or SHOULD).
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Tobias Heer <[email-masked]>
Date: Thu, 07 Jan 2010 12:51:32 +0100

Hi, 

> Baris Boyvat has implemented an experimental fault-tolerance extension for the HIP base exchange and UPDATE in the HIPL implementation. He will document it in his master thesis during this year, bu…
Great. I think this extension is really worth some deeper investigation. In our own tests with HIP(L) we found that timing and aggressiveness regarding retransmissions and opportunistic double transmissions can greatly improve the performance.

> I would like the WG feedback on whether we could include this approach in RFC5201-bis and RFC5206-bis (as MAY or SHOULD).

I would like to see this as a separate document that solely focuses on fault-tolerance and performance I think the shotgun extension is a first step to a comprehensive document. My two reasons for this are: 
a) I think solving the problem goes beyond the scope of the base documents because this problem domain offers more possible solutions than the shotgun mode. A separate document could discuss use cases and solutions in more depth than it can be done in the base documents.
b) Measures for improving fault tolerance may be quite specific to a scenario and may require to make some assumptions that cannot be made in the general case.

Some more thoughts on fault tolerance:

As far as I understood, the shotgun extension only works with multiple interfaces. What about optimizations for single-homed hosts? 

As far as I understood, the shotgun mode will make the mobile devices switch interfaces quite aggressively. What happens if the primary interface (e.g. WiFi) is temporarily down (because of a recent L2/L3 handover). The shotgun mode will determine that the secondary interface (e.g., GPRS) is working and will switch to the secondary interface? Do we need a mechanism to switch back as soon as the primary interface is available again?  

Variable timeouts and increased redundancy depending on the current situation (e.g., high packet loss -> more redundancy) might be an option, too. 

Thanks for the work you already did in this problem domain.

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: Miika Komu <[email-masked]>
Date: Thu, 07 Jan 2010 17:15:51 +0200

Tobias Heer wrote:

Hi,

>> Baris Boyvat has implemented an experimental fault-tolerance
>> extension for the HIP base exchange and UPDATE in the HIPL
>> implementation. He will document it in his master thesis during
>> this year, but I would like to start discussion of the topic
>> already now.
>> 
> Great. I think this extension is really worth some deeper
> investigation. In our own tests with HIP(L) we found that timing and
> aggressiveness regarding retransmissions and opportunistic double
> transmissions can greatly improve the performance.
> 
>> UPDATE-with-locator packets sequentially. The idea is to scan
>> through all possible source and destination IP pairs at the HIP
>> layer to improve  the chances for successful initial contact (I1)
>> and to re-establish contact (UPDATE-with-locator) in way similar to
>> the NAT-ICE extensions. We have playfully called the extension as
>> "shotgun" mode in the implementation :)
>> 
>> The obvious difference to ICE is that the shotgun mode works at the
>> HIP protocol layer. A non-obvious difference is that the approach
>> supports also fault-tolerance for a single relay/rendezvous
>> (Responder's RVS has crashed) and it can make use of multiple
>> relay/rendezvous servers for better redundancy. At the moment,
>> neither of these are possible direcly with the ICE-NAT extensions.
>> I actually believe the shotgun approach can be applied even with
>> the ICE-NAT extensions to improve fault-tolerance.
>> 
>> The shotgun approach seems useful to improve fault-tolerance with
>> an without (single or multiple) rendezvous/relay middleboxes, but
>> there is also another use case for this. The Initiator (or Mobile
>> Node) can learn multiple mappings for the peer, some of which may
>> have connectivity and some not. It is also possible that a malign
>> user intentionally sends invalid mappings for a well-known service
>> in a multiuser system (this case also requires some rate control
>> for mappings per user). In such scenarios, it is useful to try
>> multiple peer addresses sequentially instead of just single one.
>> 
>> i) Allow sending of multiple I1 and UPDATE-with-locator packets in
>> a rate-controlled fashion ii) Filter redundant incoming packets.
>> 
>> Case (ii) could be implemented as filtering of I1 packets or
>> filtering of R1 packets. We chose filtering of redundant R1 packets
>> in the implementation and it required a small change in the state
>> machine. For the UPDATE filtering, filtering based on sequence
>> numbers was sufficient.
>> 
>> I would like the WG feedback on whether we could include this
>> approach in RFC5201-bis and RFC5206-bis (as MAY or SHOULD).
> 
> I would like to see this as a separate document that solely focuses
> on fault-tolerance and performance I think the shotgun extension is a
> first step to a comprehensive document. My two reasons for this are:
>  a) I think solving the problem goes beyond the scope of the base
> documents because this problem domain offers more possible solutions
> than the shotgun mode. A separate document could discuss use cases
> and solutions in more depth than it can be done in the base
> documents. b) Measures for improving fault tolerance may be quite
> specific to a scenario and may require to make some assumptions that
> cannot be made in the general case.

Well, I am just a bit skeptic that this will be never taken into use if 
the state machine filtering part are not part of RFC5201-bis and 
RFC5206-bis.

> As far as I understood, the shotgun extension only works with
> multiple interfaces. What about optimizations for single-homed hosts?

the shotgun mode does not "care" about interfaces. It pairs up
addresses, not interfaces. So if you've got two addresses on a single
interface machine and peer has got one, two redundant packets will be sent.

> As far as I understood, the shotgun mode will make the mobile devices
> switch interfaces quite aggressively. What happens if the primary
> interface (e.g. WiFi) is temporarily down (because of a recent L2/L3
> handover). The shotgun mode will determine that the secondary
> interface (e.g., GPRS) is working and will switch to the secondary
> interface? Do we need a mechanism to switch back as soon as the
> primary interface is available again?

This is a matter of the UPDATE policy and has nothing to do with the 
shotgun extension we're proposing. The shotgun mode just means that you 
send all I1 and UPDATE-with-locator through all known source IP and 
destination IP combinations. So the shotgun mode is quite dumb and simple.

But perhaps I just misunderstood you. I haven't really thought about 
optimizing the shotgun - probably there's room for making it more clever.

> Variable timeouts and increased redundancy depending on the current
> situation (e.g., high packet loss -> more redundancy) might be an
> option, too.
> 

You're welcome.

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 20 Jan 2010 09:14:20 -0800

Hi,

FWIW, RFC5201 already allows sending multiple I1's in parallel:

6.6.1.  Sending Multiple I1s in Parallel

   For the sake of minimizing the session establishment latency, an
   implementation MAY send the same I1 to more than one of the
   Responder's addresses.  However, it MUST NOT send to more than three
   (3) addresses in parallel.  Furthermore, upon timeout, the
   implementation MUST refrain from sending the same I1 packet to
   multiple addresses.  That is, if it retries to initialize the
   connection after timeout, it MUST NOT send the I1 packet to more than
   one destination address.  These limitations are placed in order to
   avoid congestion of the network, and potential DoS attacks that might
   happen, e.g., because someone's claim to have hundreds or thousands
   of addresses could generate a huge number of I1 messages from the
   Initiator.

   As the Responder is not guaranteed to distinguish the duplicate I1s
   it receives at several of its addresses (because it avoids storing
   states when it answers back an R1), the Initiator may receive several
   duplicate R1s.

   The Initiator SHOULD then select the initial preferred destination
   address using the source address of the selected received R1, and use
   the preferred address as a source address for the I2.  Processing
   rules for received R1s are discussed in Section 6.8.

--julien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Miika Komu
> Sent: Wednesday, January 06, 2010 11:23 PM
> To: hip WG
> Subject: [Hipsec] fault-tolerance for base exchange and update
> 
> Hi,
>

---

From: Miika Komu <[email-masked]>
Date: Wed, 20 Jan 2010 19:32:05 +0200

Laganier, Julien wrote:

Hi,

I didn't recall this text, good that you noticed it. Should we also 
mention that scanning through different source addresses is ok?