Fwd: Re: Under IESG review: draft-coene-sctp-multihome-03.txt

[Alex Zinin <zinin@psg.com>]

Allison,

FYI from the RTG directorate below. Ross has good points here,
I think.

-- 
Alex
http://www.psg.com/~zinin/

This is a forwarded message
From: Ross Callon <rcallon@juniper.net>
To: Alex Zinin <zinin@psg.com>, Acee Lindem <acee@redback.com>
Cc: rtg-dir@ietf.org
Date: Wednesday, April 9, 2003, 11:24:41 AM
Subject: Under IESG review: draft-coene-sctp-multihome-03.txt

===8<==============Original message text===============
At 04:37 PM 4/2/2003 -0800, Alex Zinin wrote:
>...That part was fine. How about this:
>
> > 2.2 SCTP multihoming and the size of routing tables
> > 
> >     As multihoming means that more than one destination address is used
> >     on the host, that would mean that a routing descision must be made
> >     on the host in IP. The host does not know beforehand to which other
> >     host it is going to send something, so that would in theory require
> >     that all possible paths to all possible destinations should be known
> >     on that host. This amounts to the host being a part of the
> >     distribution of the routing information in the network.

I think that it would be a big mistake to have hosts (including servers)
running routing protocols, for several reasons (there are probably other 
reasons as well):

1. It increases the number of nodes running routing, which may have
scaling implications.

2. It makes it harder to secure the routing infrastructure (the set of all
hosts in any given network have a larger number of services turned on 
than the set of routers -- making them more susceptible to worms,
for example -- also, some of the hosts listening in might be looking
for information that they can use to attack, for example, by highjacking
  a BGP session). I think that there are many ways that this opens up
holes in the security of the routing infrastructure. 


On the other hand, the above paragraph is not completely clear to me
regarding whether it says that hosts run routing protocols. It might mean
that hosts listen in on routing protocols (which has other implications, 
such as the need to figure out whether to reliably transfer LSAs/LSPs
to hosts, and how hosts listen in on BGP -- which we might not want 
them to do). Alternatively, it might mean that routers pass routing 
information to hosts in some manner.

This ambiguity would appear to be another problem.

Also, an excerpt from section 2.1 (just after figure 2.1.4):

>         As a practical matter, it is recommended that IP addresses in a 
>         multihomed endpoint be assigned IP endpoints from different TLA's 
>         to ensure against network failure. 

Aren't TLAs "top level aggregates"? This doesn't make any sense to 
me. Are they saying that hosts should be multi-homed to completely
different backbone providers, so that if one major provider goes down
it can use another one? In many cases hosts might want to be multi-
homed to the same provider, and use two addresses which are both
from that provider's space. Alternatively, hosts might be multi-homed
to two different network segments internal to the same corporate
network, and the corporate network might itself be multi-homed to 
the same large service provider. The host might have two different 
addresses, but not necessarily from different TLAs. 

One minor nit: The acronym TLA is not actually defined in this document. 

The document only lists some issues, and in most cases doesn't give
a clear indication regarding what the solution to the issues are. I don't 
think that it even clearly states the issues. 

Thus I guess at some level I don't see the point. 

Ross




===8<===========End of original message text===========