Re: [saag] Re:

[SatishK Amara <kumar_amara@yahoo.com>]

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