Re: [saag] Re:

["IETF_DavidChen" <ietf_davidchen@hotmail.com>]

Phil,

Agreed most of your observations.

In addition to that, I would like to point out that
RSVP is bandwidth reservation protocol for guarantee IP packet delivery in
timely fashion.
It can be used for 1-to-1 or 1-to-many and initiated by the receiver to set
up a simplex flow.
Each hop along the RSVP reserved path has to commit the bandwidth.
For IP security point of view, each hop along the reserved/requested path
have to trust each other
for the bandwidth committed is vital to the router's behavior.

The (D)DOS attack to any RSVPable router can not be protected by IPSec v1.
For other sec protection,  IPSec's secured data channel has to be
established first
before RSVP signaling message.
It has to be done hop by hop - not just between flow sender and receiver.

As for protecting flow itself (after RSVP has set up the flow), IPSec can
set up only between sender and receiver...
However, I don't think this is what this thread is interested.

Scalability could be an issue to setup IPSec channel for all hops along the
requested/flow path.
If "no IPSec -> no RSVP" is not an issue, it seems ok. :-)

--- David





----- 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 11:08 AM
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
>