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

[Miika Komu <[e-mail]>]

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?

> 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