[Rsvp] RE: doubt

[Bob Lindell]

> hallo
> 
> thanks for sharing your thoughts with me. please see my comments inline:
> 
> > 
> > > hi bob!
> > > 
> > > sometimes it would be good if a error message (such as a 
> > path error) is only
> > > send to an intermediate host. you might remember the 
> > security discussion
> > > where a path message hits a node (the path msg contains an 
> > integrity object)
> > > but unfortunately the path changed and the cryptographic 
> > verification fails.
> > > hence the path message is returned to the data sender which 
> > is of no help. 
> > 
> > Why is the path message "returned"?  A packet that fails cryptographic
> > authentication is dropped.  Why should an implementation assume that
> > a message with an incorrect digest contains a valid message type (e.g.
> > a PATH message)?
> 
> if you assume that a rsvp node is always able to select the correct security
> association (and key) to protect the signaling message transmitted to the
> next rsvp node then you are done with it. 

That was the assumption when we wrote the RFC.

> 
> the question is therefore whether an rsvp node always knows its next rsvp
> aware router along the path. if it doesn't know it then it cannot secure the
> message. 

that is correct.

> 
> > 
> > > 
> > > example:
> > > 
> > >       /-------> b
> > > a ----  
> > >       \-------> c
> > > 
> > > router a forwards a path message and includes an integrity 
> > object. he
> > > assumes that the message is send to router b. unfortunately 
> > it is send to
> > > router c (because of a route change). imagine there is an 
> > entire network
> > > between a and b/c. 
> > > 
> > > hence cryptopgraphic verification fails at router c. he 
> > transmits a path
> > > error message back to the data source. this verification 
> > failure is only a
> > > problem between the participating routers. Ideally, router 
> > a would recognize
> > > this path change and would add a new integrity object with 
> > the security
> > > association shared with router c. 
> > 
> > All potential receivers should be configured to share a security
> > association with a sender LIH.  Non-RSVP clouds can make this
> > configuration more complex than would be desired.  Such is life.
> 
> sounds simple. additionally to the availablity of the keys you still have to
> know the next rsvp node to select the correct one. if you fail then you
> don't even recognize it (since you drop the message silently).

yes

> 
> imagine an rsvp signaling message which is processed at the access networks
> (because they are rsvp aware). the core networks are non-rsvp clouds. when
> the rsvp path message leaves the access network of the data sender it will
> be interpreted at the receiver's access network (edge router). 
> 
> two things sound difficult for me: 
> - how to establish the keys between these large number of networks
> - how to know which router will be hit at the other access network before
> transmitting the message to avoid selecting the wrong key

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?

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.

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
> >