Re: LIN6 and multihoming (+sec)

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 22 Aug 2001, Masahiro =Rhythm Drive= Ishiyama wrote:
> >>>>> On Sat, 18 Aug 2001 11:26:20 +0300 (EEST), Pekka Savola <pekkas@netcore.fi> said:
>
>  > I don't think people generally want to multihome every node, rather
>  > multihome a router and provide multihomed connection that way.  ID's based
>  > on EUI64 aren't possible with this mechanism if there is only one
>  > interface on end-nodes (you could just make up the other ID, I suppose,
>  > but that would be .. dirty, and no effective means of tracking them unless
>  > using some mapping function to generate them).  The fact remains that this
>  > mechanism does not seem to be fit for real multihoming.
>
> 	I don't think I understand what you mean by "ID's based on EUI64
> 	aren't possible with this mechanism if there is only one
> 	interface on end-nodes", can you clarify?

What I mean is that here, your "address" is derived from MAC address of
your network interface.  If you have two, you obviously have two
addresses.

This is apparently what was designed -- everyone using this mechanism
would be multihomed as a single node, not network.

I also see a possible usage scenario (I'm not sure if this would be really
applicable/useful there though!), where a regular router provides two
network prefixes, and the LIN6 node would only have one NIC with two
prefixes (even "rapid renumbering" if you may).  In this kind of scheme,
LIN6 would be used to gain "provider independent prefix", non-breaking
connections when active prefix changes and static ipsec associations,
among others. However, now as there is only one NIC, there is only one
address.  How do you derive the second address?

>  > Does ICMP Unreachable trigger you to retry connection using a different
>  > destination address?  IIRC ICMP unreaches are soft errors, and affect
>  > nothing.
>
> 	Our implementation has a hook to handle ICMP unreach messages.
> 	With this hook, the LIN6 node can refresh the opponent's
> 	mapping, so strictly speaking the ICMP message does not trigger
> 	a direct change of the destination address.
> 	When a node does become unreachable due to a temporary routing
> 	error and its mapping does not change, its destination address
> 	will not change.

Ok.

Placing externally available (if it is so) hook there might trigger some
additional security considerations too ("I just managed to spoof DNS cache
for a few seconds, get the wrong new address now!").

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords