[Rsvp] RE: doubt

[Tschofenig Hannes]

hi 

> 
> That was the assumption when we wrote the RFC.
> 
> Remember, this is hop-by-hop integrity.  If you define a single hop
> as crossing the core of the Internet, then you have substantially
> changed the model of RSVP deployment. How do you guarantee any
> level of QoS in the core?

i guess that this is the source of the problem. the assumtion was fine when
designing rsvp as a signaling protocol for intserv. however, people have
added extensions to the protocol and used the protocol for different things.
in these scenarios / environments this assumption does not necessarily hold.
unfortunately people tend to extend the functionality but forget to look at
the security again (the only reference the original security documents). 

that's not your fault for sure. 


> 
> Internet scale key management issues are more in the domain of RSVP
> policy objects.  When signalling requests are passed from one domain
> to another domain, there needs to be a mechanism to authenticate
> and authorize the request (and bill the customer).  Simple hop-by-hop
> message integrity mechanisms are not meant to address those problems.

my personal opinion: the policy objects tried to repair the missing key
management to some extend (i.e. they provide the user identity for the
purpose of policy based admission control). 

the hop-by-hop security is perfectly fine for the charging model currently
used in the internet. i will send around a document giving detailed reasons
for this statement in the near future. 

ciao
hannes


> 
> Bob Lindell
> 
> > 
> > 
> > ciao
> > hannes
> > 
> > 
> > > 
> > > 
> > > Bob Lindell
> > > 
> > > > 
> > > > ciao
> > > > hannes
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: owner-rsvp@ISI.EDU [mailto:owner-rsvp@ISI.EDU]On 
> > > Behalf Of Bob
> > > > > Braden
> > > > > Sent: Tuesday, September 17, 2002 12:01 AM
> > > > > To: rsvp@ISI.EDU; hemanth_khare@rediffmail.com
> > > > > Cc: schultz@io.iol.unh.edu
> > > > > Subject: Re: doubt
> > > > > 
> > > > > 
> > > > >   *>    After reading this section what i have in mind is 
> > > > > that error in 
> > > > >   *> the PERR message will be reported to the sender 
> > > (data source).
> > > > >   *> 
> > > > >   *>    But the error may be caused by the intermediate 
> > > > > nodes. In that 
> > > > >   *> case error must be reported intermediate node and 
> > > not to sender 
> > > > >   *> application (data source).
> > > > >   *> 
> > > > > 
> > > > > What good would it do to notify intermediate nodes, when the
> > > > > error is caused by erroneous data from the sender RSVP?
> > > > > Only the sender is in a position to correct the error.
> > > > > 
> > > > > Bob Braden
> > > > > 
> > > > >   *>    Please let me know ur thoughts on this aspect.
> > > > >   *> 
> > > > >   *> TIA and Regards,
> > > > >   *> -hemanth
> > > > >   *> 
> __________________________________________________________
> > > > >   *> Give your Company an email address like
> > > > >   *> ravi @ ravi-exports.com.  Sign up for Rediffmail 
> Pro today!
> > > > >   *> Know more. http://www.rediffmailpro.com/signup/
> > > > >   *> 
> > > > _______________________________________________
> > > > Rsvp mailing list
> > > > Rsvp@mailman.isi.edu
> > > > http://mailman.isi.edu/mailman/listinfo/rsvp
> > > _______________________________________________
> > > Rsvp mailing list
> > > Rsvp@mailman.isi.edu
> > > http://mailman.isi.edu/mailman/listinfo/rsvp
> > > 
>