Re: [saag] Re:

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

Hannes,
My reply to your particular question is in-line.
--- David

----- Original Message -----
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "IETF_DavidChen" <ietf_davidchen@hotmail.com>; "Hallam-Baker, Phillip"
<pbaker@verisign.com>; "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'"
<alaadas@kaau.edu.sa>; "Davenport Michael" <davenport_michael@bah.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, June 06, 2002 11:07 AM
Subject: RE: [saag] Re:


> hi david
>
> > 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.
>
> actually it is a signaling protocol. it does not really reserve bandwidth
or
> any other qos things. this is the purpose of the underlying qos
mechanisms.
>
> > It can be used for 1-to-1 or 1-to-many and initiated by the
> > receiver to set
> > up a simplex flow.
>
> good point. so far we haven't mentioned the rsvp multicast implications
for
> security.
>
> > 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.
>
> i would like to add that not all nodes have to trust each other directly.
> instead the chain-of-trust principle uses the transitive trust
relationship
> between the individual nodes along the path to establish the end-to-end
> trust rel..

Without IPSec (or similar security model), the RSVPable routers have to
reject any RSVP message
from unknown routers - practically everyone.  (all kinds of attack could
happen :-)

All the RSVPable routers along the flow path have to be at the same level of
IPSec protection.

Furthermore, all the routers that have been requested resource (for RSVPable
router) have
to be at the same level of IPSec protection.

I suppose the members of the chain-of-trust are those RSVPable routers.

>
> >
> > The (D)DOS attack to any RSVPable router can not be protected by IPSec
v1.
>
> to which dos attack are you exactly referring?

Current IKE of IPSec can not protect (Distributed) Denial of Service
attack... and don't mention about
RSVP depends on it to setup a secured channel.


>
> > For other sec protection,  IPSec's secured data channel has to be
> > established first
> > before RSVP signaling message.
>
> yes.
>
> > It has to be done hop by hop - not just between flow sender and
receiver.
>
> true, it cannot be done end-to-end because of various reasons including:
> - rsvp message modification along the path
> - route pinning
> etc.
>
> >
> > 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.
>
> yes - the protection of data traffic after the rsvp signaling took place
> using ipsec is a different issue.
>
> >
> > Scalability could be an issue to setup IPSec channel for all hops
> > along the
> > requested/flow path.
>
> the question of scalability depends how many rsvp aware nodes along the
path
> you have.
> futhermore ipsec (in a hop-by-hop manner) may also be used for a specific
> part in the network (for example between two network providers) whereas
> other parts use the rsvp built-in integrity object.
>
> > If "no IPSec -> no RSVP" is not an issue, it seems ok. :-)
> i am not quite sure what you mean with this statement.

If it requires IPSec to protect RSVP then it needs to ask all RSVPable
routers must
have IPSec.   This is an issue if RSVPable router is in the 'cloud'.
The IPSec is expected to implement on edge of the 'cloud' for effeciency.
This also bring up an important issue about how effective the RSVP is when
NOT all the router along the flow path is RSVPable router.
The worest case will be only the 2 RSVPable routers are on the edge of 'IP
cloud' that are sender side and receiver side
respectively.  :-)
The IPSec (or security issue) is just one more factor to complicate the
effectiveness of RSVP in the public IP network.

It seems that a secured channel between the RSVPable router can help the
'trusted router resource allocation' issue.
However, if RSVPable routers are in the cloud (which will increase the
effectiveness of the purpose of IP QoS),
then the secured comm level is better on the RSVP message level - not IP
level. (i.e. other than IPSec ;-)

>
> ciao
> hannes
>
>
>