RE: RE: doubt

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. 

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. 

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

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


ciao
hannes


> 
> 
> Bob Lindell
> 
> > 
> > ciao
> > hannes
> > 
> > 
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]]On 
> Behalf Of Bob
> > > Braden
> > > Sent: Tuesday, September 17, 2002 12:01 AM
> > > To: [email protected]; [email protected]
> > > Cc: [email protected]
> > > 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
> > [email protected]
> > http://mailman.isi.edu/mailman/listinfo/rsvp
> _______________________________________________
> Rsvp mailing list
> [email protected]
> http://mailman.isi.edu/mailman/listinfo/rsvp
> 
_______________________________________________
Rsvp mailing list
[email protected]
http://mailman.isi.edu/mailman/listinfo/rsvp