[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [saag] Re:



 Satish,
Agreed,
Let's work on RSVPSec. :-)
--- David

----- Original Message -----
From: "SatishK Amara" <kumar_amara@yahoo.com>
To: "IETF_DavidChen" <ietf_davidchen@hotmail.com>; "Hannes Tschofenig"
<Hannes.Tschofenig@mchp.siemens.de>; "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 4:05 PM
Subject: Re: [saag] Re:


> Hi,
>   Please look for my inline comments ..
> --- IETF_DavidChen <ietf_davidchen@hotmail.com> wrote:
> > 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.
> >
>  IKEv2/JFK addresses DOS attacks
>
> > >
> > > > 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 ;-)
> >
> I agree with you the security for RSVP should be at
> message level rather than IP level. I think this is
> due to couple of reasons. IPSEC cannot address the
> security aspects of RSVP
>   RSVP next hop is determined dynamically.
>   RSVP messages changes from hop to hop
>   Need for both hop to hop and end to end security
> mechanism for RSVP
>
> Satish Amara
>
> > >
> > > ciao
> > > hannes
> > >
> > >
> > >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>