Re: [saag] Re:

["Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>]

Phillip

I believe that the CORBASec and SECIOP in its design offer features for
end-to-end message transit without you have to make various scenarios each
day of attacks on IPSec. You got to look into the protocol architecture to
realize that it is true a different ideology, but rather a sound one in my
view,  instead of  building upon the old tech of TCP/IP and Cryptology.
Looking at the ISO/OSI seven layers. CORBA/GIOP/IIOP/SECIOP can offer
features that are more modular and secure. I do not know why major IP
vendors abandoned CORBA, but look in the literature and you will find that
they might come back to it. My estimate is that they are worried about
investments in current products.


Ahmed



----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" <alaadas@kaau.edu.sa>;
"Davenport Michael" <davenport_michael@bah.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, May 30, 2002 6:08 PM
Subject: RE: [saag] Re:


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