RE: [saag] Re:

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

> Mike
> 
> I believe most big vendors are looking at it right now, see

I don't. I know of more major platform vendors who are stating that they
have no intention of further work on CORBA than are platform members of OMG.
The only major companies with Platform membership of OMG at this stage are
Motorola, Rockwell Collins and DaimlerChrysler. These are not names I
usually associate with IP routing.

> The best approach in my view is to use CORBA and CORBsec to deal with path
> messages, I believe if CORBA routers can be realized very soon, most of
your
> IPsec shortcomings will be resolved.

How?

There are several companies that have built Web Services SOAP routers. It is
not immediately apparent to me how any of their products is relevant to this
problem.


The problem is essentially caused by the introduction of a feature that
requires a degree of trust in what is considered by the IPSEC threat model
to be an untrusted device.

I suspect that the QoS problem cannot be solved through application of the
end-to-end principle. This should not be a great suprise since the
end-to-end principle is a conclusion, not an axiom. Those that treat it as
an axiom are likely to get overly ideological about the issue.

The end-to-end argument was originally an argument about complexity.
Complexity is easier to manage at the edge of the network rather than the
middle. This morphed into a subtly different security argument that the
security context of a message should be managed 'end-to-end'. This is a
problematic argument since a transaction may have many messages and the
'ends' of the transaction may not align with the 'ends' of the constituent
messages.

While it is nice to build theoretical models in which the only trusted
parties are the end points, QoS inherently depends on the end points
trusting each of the intermediate routers to meet the necessary QoS
characteristic.

Furthermore the routers must trust the originator of any QoS messages since
otherwise a malicious user may perform a DoS attack against the entire
network by issuing bogus QoS reservation messages.

[Observation, QoS is not an issue if the network resources are not
constrained in some manner]

This latter problem indicates to me that it is not feasible to support QoS
on an unrestricted public network without some form of resource management
mechanism (probably related to monetary payment) to support it. What could
be a tricky problem of trust is thus simplified, instead of the hard problem
of 'is it Alice' we have the easier problem of 'can she pay'. The trust
relationships precisely align to the relationship between resource
allocators.

The resulting business models may or may not turn out to be 'all you can
eat'. I suspect however that some incentive is required.


This problem appears to me to require the following components:

	1) Trustworthy routing information
	2) Means by which a router may determine that a reservation message
is signed by a trustworthy actor.
	3) Means by which a router may notify charging mechanism

The end-to-end principle indicates that the routers should certainly not be
performing heavyweight crypto. 

The model I would favor would involve some form of bandwidth reservations
actor that can perform processing of the bandwidth reservation request then
issue RSVP messages tagged with MAC authenticators and Kerberos tickets for
each of the routers concerned.


		Phill