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

["Laganier, Julien" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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,
> 
> 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.
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec