My understanding is that there are two things, that may be considered
independently:
- configuring IPsec layer
- defining which route the communication should take
I don't understand why only one tunnel should be used. A mobile node, when
it detects a new interface, should be able to "add" this Interface on the
already existing tunnel. It looks to me as a limitation of MOBIKE. * This
would would allow the mobile node to use multiple tunnels. Which tunnel to
choose depends on other inputs. The important thing is that the mobile can
can use multiple tunnels. **
* "adding" could mean deriving a new SA from the old tunnel. This important
thing here seems to avoid re-doing an IKE exchange.
** this would require that SPD-O is derived per interface. Since a single
SPD is ordered and will always provide the same first match. I am not sure
how that can be implemented and would appreciate feed backs on that point.
Regards,
Daniel
On Mon, Mar 26, 2012 at 11:04 AM, Michael Richardson
<[email protected]>wrote:
>
> >>>>> "Vishwas" == Vishwas Manral <[email protected]> writes:
> Vishwas> Branch routers have 3G/ 4G interfaces as backups for the
> Vishwas> primary interface
> Vishwas> and sometimes even multiple 3G/ 4G interfaces with no wired
> Vishwas> interface at
> Vishwas> all to the backend.
>
> Vishwas, it's not about requirements on immobile branch offices, or
> *they* connect to the internet.
>
> It's about laptops/smartphones which are typically "remote" on various
> interfaces (including 3G and wifi going up/down regularly), and what
> happens when such a device is now *inside* a branch office.
>
> (A laptop with an ethernet is more likely to be 'inside' the branch
> office than a laptop/smartphone with wifi at the office, depending
> whether the WIFI is bridged to LAN, or the wifi is considered untrusted)
>
> How does this device learn that it should now rely in the branch
> office's MESH membership, rather than it's own MESH membership?
>
> I don't think that the title of this ticket is well chosen.
> I can do a diagram.
>
>
>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
