Subject: RE: network controls are neccessary

From: Erik Nordmark <[email-masked]>
Date: Fri, 6 Dec 2002 08:46:47 +0100 (CET)

Sorry for the delayed response.

> > Erik Nordmark wrote:
> > For instance, would it make sense to push
> > all of the rules into the hosts
> 
> Be careful, Craig might have a heart attack just at the thought of doing
> it. There would be terrible security consequences. I don't see how this
> could be anything else than pushing subnet-specific rules to the hosts
> that belong to the subnet.
> 
> > or is the set of rules so large that a host-based
> > solution would need to cache subsets of the rules
> > on demand?
> 
> It's not a matter of size but complexity.
> 
> First, the hosts do not have the intelligence that routers have. For
> example, how long is it going to take before all hosts implement the
> equivalent of a route-map? Are you going to enable an IP phone to
> process BGP communities? Pushing all the rules to hosts would imply
> either:

I did not suggest that hosts should run BGP. That would be completely silly.
But IPv6 hosts are supposed to have a source address selection table
according to a draft in the IPv6 WG (soon RFC).
If the exit routing policy can be expressed with a few rules it
would essentially be additional rules in that table (and a protocol
by which the hosts can learn those rules).
Hence my questions on the list (so far without answer) about reasonable
sizes for the exit router selection policy/routes.
 
> a) The hosts to have the same routing capabilities as routers currently
> have.

Sorry I don't follow the logic. The hosts don't route. Hosts with multiple
source locators that talk to a node with multiple destination locators
just do a selection e.g. when creating a new connection.

> b) The rules have to be modified to accommodate dumber hosts.
> 
> Second, part of the configuration of a router is the router's location,
> which is implied. Pushing policies to the hosts would require a coupling
> between the topological database and the routing policies that is beyond
> what most large companies typically have (not to mention that it is
> questionable that such a monster could be maintained).
> 
> One in the other, the sad truth is that multiple addresses per host do
> not fly in the large organization. What is not flying either is policy
> that is not at the edge for egress traffic (stateful firewall issues,
> etc). We have had multiple posts about this on mh.

I'm not talking about today - I'm talking about a future solution which 
separates identifiers and locators end2end e.g. using Pekka Nikander's proposed
HIP approach. In that case the administrative cost of the additional locators
would be close to zero.
And you could get reasonable security.

> There is nothing fundamentally wrong in having multihoming schemes that
> use several addresses, but this should be virtualized at the edge of the
> network, which is basically what MHAP does.

I think the edge thing is also important to explore in parallel with
a host-based scheme.
Getting a handle on the security aspects (starting with a threat analysis)
for the edge solutions would be quite useful IMHO.

  Erik

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 Dec 2002 10:35:50 -0500

Expecting hosts to have useful logic to perform source address selection 
seems a recipe for trouble in multiple regards.
Recognizing and selecting link local addresses is probably not an 
issue.  But as soon as you step beyond that, things break.  They break in 
two different ways at once.

In one regard, you end up needing significantly more logic in the host to 
make any kind of intelligent choice.  This means more code, more state, and 
more things for the network administrator to configure (probably incorrectly.)
Secondly, you couple the hosts into the behavior of the rest of the routing 
system, reducing the ability of the system to cope with changes (either 
network changes or protocol changes.)

If we really want the hosts to make the choice (a concept I am doubtful of) 
I suppose we could invent a query / response protocol for the purpose of 
asking a routing intelligent server what source /dest pair from a given set 
of sources and dests would be a good pair to use.

I strongly prefer the notion that other entities in the system would make 
the intelligent choice about the source address to use, and could change 
that choice as necessary.

Yours,
Joel M. Halpern

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 06 Dec 2002 11:05:45 -0500

> of sources and dests would be a good pair to use.

one problem with that interface is that if the host determines that
the recommended address pair doesn't work and wants to try something
else, it has no idea whether to blacklist the source, the destination,
or both, when it next asks.

and it would be good for scalability if the host could know when it
was appropriate to cache the results.

						- Bill

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 Dec 2002 11:35:27 -0500

Thinking about this question (of what the host might know / want) I think 
that there are several things that should be teased apart:

1) The address pair does not work because there really is no connectivity 
over that path.  In that case, presumably routing will catch up pretty 
quickly.  In the mean time, it is probably unlikely that trying random 
combinations will produce better results.

2) The "doesn't work" is in some sense other than connectivity.  This has 
been alluded to by some folks in the discussion.  Trying to get some kind 
of service behavior out of address selection is clearly a matter of using 
the wrong tool for the wrong problem.

3) There is a corner case of some unusual failure that means that some 
locator for the remote host is not useable, but still appears fine in 
routing.  The mechanisms for resolving locators ought to deal with that, 
not the connecting host.

For clarity, I would actually prefer to have the hosts have nothing at all 
to do with the locator selection.  The host may need a mechanism to say 
"this communication appears not to be working" to cause the routing system 
to take appropriate local steps.

Yours,
Joel M. Halpern

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Dec 2002 12:32:43 -0500

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:
    Joel> In one regard, you end up needing significantly more logic in the host to 
    Joel> make any kind of intelligent choice.  This means more code, more state, and 
    Joel> more things for the network administrator to configure (probably incorrectly.)
    Joel> Secondly, you couple the hosts into the behavior of the rest of the routing 
    Joel> system, reducing the ability of the system to cope with changes (either 
    Joel> network changes or protocol changes.)

  On the other hand, it scales, and is far more friendly to end-to-end.

  The host already has to maintain the indexes to demux the connections, and
may already have significant state invested in the connection.

    Joel> If we really want the hosts to make the choice (a concept I am doubtful of) 
    Joel> I suppose we could invent a query / response protocol for the purpose of 
    Joel> asking a routing intelligent server what source /dest pair from a given set 
    Joel> of sources and dests would be a good pair to use.

  Yes, we will need such a protocol.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 6 Dec 2002 09:52:23 -0800

Joel M. Halpern wrote:
> ...
> In one regard, you end up needing significantly more logic in 
> the host to make any kind of intelligent choice.

By 'intelligent' you mean 'the same policy choice as the network admin',
right? This is not really a technical problem as much as a domain of
control problem. The address selection rules allow for local
administration. So if a network manager can convince the local host
manager to set source selection policy to prefer a specific order from
the list of prefixes in an RA, "the intelligent thing will happen". If
the network admin can't do that, the hosts are effectively uncoordinated
traffic sources that any transit ISP has to deal with already.
Attempting to dictate operational policy through a standards process is
going to fail.
  
> This means more code, more state, and 
> more things for the network administrator to configure 
> (probably incorrectly.) Secondly, you couple the hosts into 
> the behavior of the rest of the routing 

This looks like a big problem to the network admin, because they are
used to dealing with a few boxes, but for a host admin, this is exactly
what they do. What needs to happen here is for them to work together
(*gasp*).

> of sources and dests would be a good pair to use.

If you want the ability to change policy in real-time from the network,
it makes much more sense to put options in the RA than create a
query/response protocol. 

> that choice as necessary.

Even though accomplishing that will require changing all the application
software globally???

Tony

> >I did not suggest that hosts should run BGP. That would be 
> completely 
> >silly. But IPv6 hosts are supposed to have a source address 
> selection 
> >table according to a draft in the IPv6 WG (soon RFC). If the exit 
> >routing policy can be expressed with a few rules it would 
> essentially 
> >be additional rules in that table (and a protocol by which the hosts 
> >can learn those rules). Hence my questions on the list (so 
> far without 
> >answer) about reasonable sizes for the exit router selection 
> >policy/routes.
> >
> > > a) The hosts to have the same routing capabilities as routers 
> > > currently have.
> >
> >Sorry I don't follow the logic. The hosts don't route. Hosts with 
> >multiple source locators that talk to a node with multiple 
> destination 
> >locators just do a selection e.g. when creating a new connection.
> 
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 Dec 2002 13:02:42 -0500

If I thought having the network make the selections would require change in 
application logic, I would not be suggesting such a solution.
I would prefer a solution that is completely invisible to the application 
(such as Tony Li's suggesting that the application is handed a 32 bit 
identifier when it currently expects an IP address).
Failing that, I would prefer to minimize the application coupling.
Having application level address selection increases the application impact.

Yours,
Joel M. Halpern

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Dec 2002 10:15:52 -0800

> what they do. What needs to happen here is for them to work together

This is the end to end argument run amok.  If this truely is an 
assumption then Joel is right, and this is a recipe for failure.  You 
were right to gasp because more often than not in large companies this 
is *not* the case.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 7 Dec 2002 19:52:38 +0100 (CET)

> Having application level address selection increases the application impact.

A few weeks back, on the IETF discussion list in the "kernelizing the
address lookup" (or similar) thread, the opposite point was made, by
several people if I remember correctly.

Some applications need to see more than just the host name. If we are
going to build something where a host can have several addresses tied to
several paths with different properties (fast/slow, secure/insecure,
free/cheap/expensive), applications will want to make selecting
addresses their business.

Currently, IPv6 doesn't support backwards compatibility with
applications that use the traditional socket API. The past three days
I've been trying to find a web browser with IPv6 support for my new
iBook, so I think I've earned the right to say there aren't enough IPv6
applications yet that breaking those is a big issue. However, if we go
down the path of requiring applications to change, we should make very,
very, very sure this is a one time thing and we build in everything we
need for IPv6 - IPv15.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 07 Dec 2002 14:02:35 -0500

As far as I know,
1) We do not have paths that provide these properties
2) If we had such paths, the likelihood is that the host would not have 
enough information to determine which locator would give the desired 
properties.

Yes, there is (and has been for many years) ongoing discussion of QoS.  We 
still have not found a sensible and useful way to provide differentiation 
in that dimension.

One of the reasons I want to keep hosts out of the routing space is that if 
we ever do find routing solutions that we want to use for new capabilities 
(QoS or otherwise) I would not want to have to upgrade the hosts as well as 
the routers to deliver such capabilities.

Yours,
Joel M. Halpern

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 7 Dec 2002 23:02:13 +0100 (CET)

> 1) We do not have paths that provide these properties

Sure we do, hosts such as laptops routinely have different interfaces
connecting to different services with different properties. Today, we
typically don't use those at the same time, but it's not a big leap to
expect this will happen more in the future. For instance, if I'm walking
around a convention center with my laptop while I'm downloading a file
and I'm looking at a device over a telnet/SSH connection, I would like
both of these applications to use wireless LAN connectivity if
available. But when I'm out of range of the wireless LAN, I'd want the
terminal connection to switch to GPRS or something similar, but the
download should simply stop and resume later when there is more/cheaper
bandwidth.

> enough information to determine which locator would give the desired

In the example above it does. If selecting the path is done further
upstream (border router) then a host wouldn't automatically know this,
yes. The question then becomes: do we want the applications to know the
properties of different paths and then select one, or do we want the
applications to tag their packets with something that indicates the
desired service level, and let the routing infrastructure take it from
there?

I've heared arguments that hosts are plenty smart and can do everything
routers can. This would mean that the ultimate decision is the host's,
and that the routing infrastructure only provides the necessary building
blocks. But I don't buy this. People sitting in a bus can also be
excellent drivers, but that doesn't mean they get to second guess the
bus driver. Hosts need to look after the applications running on them,
routers need to look after the network as a whole. Getting routers to
work together is hard enough, getting hosts which are much more diverse
in every way to do the same is next to impossible. However, that does
not mean hosts should be kept stupid: any task a host can perform
autonomously without adverse effects on other systems should be
performed by the host and not by the network infrastructure.

> still have not found a sensible and useful way to provide differentiation

The same was true for interdomain multicast for a long time. But as far
as I can tell, it works fine now for those who have a transit provider
that supports it.

I think the QoS effort hasn't been as productive as it could have
because the focus has mainly been to split the bandwidth for a single
link (or sequential set of links) in creative ways. However, this is
only a useful approach if most of your traffic is bulk that can be
throttled back if there is higher priority traffic. But oversubscribing
regular traffic and then investing in equipment that can throttle it
back even further doesn't work nearly as well as simply putting that
money towards bigger pipes.

However, not all bandwidth problems can be solved with bigger pipes: you
can get only so many bits per second through a radio channel, especially
if there are antenna size, power, mobility and interference constraints.
So I think there is a future for QoS mechanisms that can make
applications run free over cheap/bandwidth-rich links but tome them in
over expensive/bandwidth-starved links.

An interesting observation: while hosts with biggest links now have
17,000 times as much bandwidth as those connected to the original
Arpanet, the hosts with the smallest links actually have 6 times _less_
bandwidth as those early Arpanet hosts 30 years ago.

> the routers to deliver such capabilities.

I agree 100%.

Iljitsch

---

From: Eliot Lear <[email-masked]>
Date: Sun, 08 Dec 2002 14:50:33 -0800

> download should simply stop and resume later when there is more/cheaper

And this is easily accomplished without any support from the routing 
system today.  All it requires is an ACL saying what sort of traffic is 
allowed on a given link.  In two words, access lists.

That has NOTHING to do with the routing system.

Eliot