Subject: LIN6 and multihoming (+sec)

From: Pekka Savola <[email-masked]>
Date: Sat, 18 Aug 2001 11:26:20 +0300 (EEST)

[http://www.ietf.org/internet-drafts/draft-teraoka-ipng-lin6-01.txt]

As LIN6 was presented at multi6, and I don't know of a better place to
comment on this, I guess I'll just post these here..

The fact is that the multihoming support of LIN6 is only limited to single
nodes, clearly made cellular mobiles in mind:

3.9.  Multi-Homing Support

    Figure 6 shows multi-homing support in LIN6.  In the figure, Node-B is a
    multi-homing host which has two network interfaces.  Node-A and Node-B
    have the LIN6 generalized ID, "LIN6_P+ID_A" and "LIN6_P+ID_B",
    respectively, where "LIN6_P" is the LIN6 Prefix, and "ID_A" and "ID_B"
    are the identifiers of Node-A and Node-B, respectively.  Node-A has the
    LIN6 address, "P_A+ID_A", where "P_A" is the network prefix of Node-A.
    Node-B has two LIN6 addresses, "P_B1+ID_B" and "P_B2+ID_B", where "P_B1"
    and "P_B2" are the network prefixes of Node-B corresponding to the two
    network interfaces.
[...]

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.

Also:

[...]
       2. Assume that Path_A crashes due to some reason, and ICMP Unreach is
          returned to Node-A.

       3. Node-A knows that Path_A is unavailable and selects "P_B2" as the
          network prefix of Node-B.

Does ICMP Unreachable trigger you to retry connection using a different
destination address?  IIRC ICMP unreaches are soft errors, and affect
nothing.

I don't comment on non-multihoming issues, except for the fact that there
are no "Security Considerations" in the text.  It appears to me that if
you use generalized network prefix as e.g. TCP/UDP endpoints, capturing
traffic, hijacking connections etc. are bound to be at least potentially
easier (as the generalized LIN6 namespace is flat); this puts even more
responsibility for the security of DNS and mapping agent functions.

-- 
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

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Sat, 18 Aug 2001 08:58:02 -0400

I'd like to use this comment as a springboard to what might be called 
a meta-discussion of multihoming requirments.

At 11:26 AM +0300 8/18/01, Pekka Savola wrote:
>[snip]
>multihome a router and provide multihomed connection that way.

This is where I partially disagree. Yes, I can understand that it is 
generally not required to multihome cellular mobile hosts.  I hope I 
may be forgiven for loose terminology if I call them "clients."

"Server" hosts, in contrast, very reasonably will be multihomed to 
routers. Indeed, there may be complex relationships of multiple 
servers and multiple routers.

The mechanism of server to router multihoming will vary with the 
application. When the multiple routers are on the same subnet as the 
server, a mechanism as simple as VRRP may suffice, perhaps with 
multiple VRRP groups for a degree of load-sharing.  As the servers 
and routers become more distributed, some NAT or transport based 
mechanism may be needed, or the servers may need some awareness of 
routing.

Howard Berkowitz
Nortel Networks

---

From: Pekka Savola <[email-masked]>
Date: Sat, 18 Aug 2001 16:43:35 +0300 (EEST)

> may be forgiven for loose terminology if I call them "clients."

This isn't a point, but there might be some justification for it so...

Multihoming cellular clients might be feasible if the underlaying
structure is made so that the address would change if they changed their
radio base station.  Then, when you move to some direction, it might be
prudent to start to "prepare way for the handoff" by multihoming with
current and the next cell you're moving towards when you're close enough
to the edge.

> mechanism may be needed, or the servers may need some awareness of

(I'm assuming here that multihoming is done to ensure redundancy.  There
are other reasons too, of course, but I'll skip them here.)

I agree.  This depends heavily on how important and costly multihoming is
(ie. do you want to also multihome systems that strictly speaking might
not need it so much, e.g. workstations vs. critical web-servers).

If we can't find a good way to multihome entire sites, it just _might_
(for an intermediate approach, if not else) be sufficient to be able to
multihome certain critical systems.

The amount of critical systems and how they're located in the site's
network topology defines whether "server-based" or "network-based"
multihoming is a better alternative (if you actually could do it either
way).

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Sat, 18 Aug 2001 10:36:15 -0400

>>  may be forgiven for loose terminology if I call them "clients."

And just to disagree with myself, there might be unusual and critical 
applications where a mobile "end user" might need high availability, 
such
as a telepresence application in field emergency medicine.  In such 
cases, the question becomes, is "multihomed routing" enough? 
Certainly multihomed routing protects against certain failures. It 
wouldn't protect against a failure of the base station for a cell, if 
both "homings" are to it.  It wouldn't protect against a hardware or 
system software failure of the host.

I feel it's important that the requirements make very clear that 
multihomed routing only protects against certain failure modes. 
http://www.ietf.org/internet-drafts/draft-berkowitz-multireq-02.txt, 
which I wrote with Dima Krioukov, and hope to merge with current 
multi6 requirements, provides pointers to "multihoming" at other 
layers.

>current and the next cell you're moving towards when you're close enough

Especially if the client has GPS and knows its direction, it might be 
interesting (although annoying to the cellular protocol folk) to 
introduce a query message that asks "hey, current base station...what 
cell(s) is northwest of you?"

>not need it so much, e.g. workstations vs. critical web-servers).

Depends on the industry and application.  There's no question that a 
CT or MRI scanner workstation is critical, but if the scanner/server 
itself fails, workstation redundancy doesn't help much.  As a matter 
of fact, I was in an MRI scanner at a research hospital last year, 
and the UNIX server kept crashing.  I kept volunteering to help 
debug, but that merely resulted in red faces on the part of the staff.

I think we need to distinguish, in the non-mobile space, between 
workstations and multiple interface workstations.  Someone like a 
money trader has a critical application, and, while they might not 
have a wholly separate workstation, it's quite common for their 
stations to have an active and a backup NIC, connected to separate 
LANs going to high-availability server clusters.

---

From: Masahiro Ishiyama <[email-masked]>
Date: Wed, 22 Aug 2001 20:34:06 +0900

>>>>> On Sat, 18 Aug 2001 11:26:20 +0300 (EEST), Pekka Savola <[email-masked]> said:

 > 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?

 > destination address?  IIRC ICMP unreaches are soft errors, and affect

	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.

 > responsibility for the security of DNS and mapping agent functions.

	You present some good points and we plan to address these issues in
	future drafts. For now, we would like more people to test our
	implementation to get feedback so that we can effectively integrate
	our proposal with DNS and mapping agents. If you have any interest
	at all in LIN6 please try our prototype implementation.

masahiro