Re: Policy control for RSVP

[Kaustubh Phanse <kphanse@ee.vt.edu>]

Hi! Paolo,

	Thanks for your reply. Yes, I just wanted to confirm/compare the
trade-offs and implications of doing or not doing access authorization for
the PATH message. The main driving factor of doing this mainly looks to
be more of a security stand-point (denial of service etc.) than
QoS or resource reservation itself, since the bandwidth reservation and
connection set-up is not complete anyway till the RESV message gets back
to the sender.

Thank you
regards
Kaustubh
-----------------------------------------------------------------------------
On Fri, 13 Jul 2001, Molgora Paolo wrote:

> Sorry,
> 
> but for my understanding to check resource authorization policies
> on RESV msg means to execute the control after the connection is
> already established. This for my point of view cause the following
> problems if the check fails:
> - it is provided a not authorized service also for a few time;
> - the connection just created has to be destoyed;
> 
> What I had understood was to execute all the checks at the PATH request
> in order to block the request suddenly;
> this solution could take time to create a path (i.e. wait PDP decision as you said),
> but it is anyway irrelevant wrt the global path set-up activities that today an
> operator
> has to do on the network.
> 
> I thank you in advance for any answer.
> 
> Paolo
> 
> kphanse@ee.vt.edu wrote:
> 
> > Hi! Diana,
> >
> >         Thanks for your reply. I do understand that this could be one way
> > to do it and is generally mentioned in most RFCs/published papers. But, I
> > am not yet sure whether this is the ONLY way to do it.
> > Can't both the access and resource authorization policies be performed
> > only on the RESV message? I guess for "valid" RSVP flows, the advantage in
> > doing this seems to be two-fold: (1) Reduction in the set-up time, since
> > now the PEP will forward the PATH message without having to wait for PDP's
> > decision, and (2) Reduction in amount of signalling overhead. Isn't it?
> > Please correct me if I am wrong.
> >
> > Thank you very much.
> > regards
> > Kaustubh
> >
> > -----------------------------------------------------------------------------
> > On Tue, 3 Jul 2001, Rawlins, Diana wrote:
> >
> > > Kaustubh,
> > >
> > > IMHO I would perform access authorization policies on the Request
> > > PATH and resource authorization oriented policies on the Request
> > > RESV.
> > >
> > > -Diana
> > >
> > >
> > > -----Original Message-----
> > > From: Kaustubh Phanse [mailto:kphanse@ee.vt.edu]
> > > Sent: Monday, July 02, 2001 6:48 PM
> > > To: rap@ops.ietf.org
> > > Subject: Policy control for RSVP
> > >
> > >
> > >
> > >       Re-sending the message (please see below) that I had sent a few
> > > days back. Did not really receive any response...so I am not sure if my
> > > query was too naive?! But, either way, I would be grateful if someone
> > > could please help me with this. Even after reading the RFCs/drafts, its
> > > still not clear why/whether there is a need for policy control on BOTH the
> > > PATH and RESV messages for a given RSVP flow.
> > >
> > > Thank you very much.
> > > regards
> > > Kaustubh
> > >
> > > ----------------------------------------------------------------------------
> > > -
> > > On Fri, 22 Jun 2001, Kaustubh Phanse wrote:
> > >
> > > >
> > > >     Just wanted to clarify my understanding of the policy
> > > > control/processing of PATH and RESV messages.
> > > >
> > > >     To successfully implement policy-based admission control, during
> > > > the initiation of an RSVP reservation, is it really "necessary" to enforce
> > > > policy control on both PATH and RESV messages? I understand that policy
> > > > elements in PATH message can be used to authenticate users/applications
> > > > and the corresponding Tspec. But this may be achieved even by
> > > > policy control of the RESV message. So, even if PEP on the sender side
> > > > does not perform any policy-based admission control on an "invalid" PATH
> > > > message and lets it flow to the receiver, the PEP on the receiver-side
> > > > should be able to "reject" the resulting "invalid" RESV message...right?
> > > > And hence such a policy framework should still work? Is there a scenario
> > > > where this is NOT the case and policy control on both PATH and RESV
> > > > message is "critical" for successful enforcement of PAC.
> > > >
> > > > Please forgive my ignorance on this topic! :) Any comments/clarifications
> > > > are more than welcome.
> > > >
> > > > Thanks in advance.
> > > > sincerely,
> > > > Kaustubh
> > > >
> > > ----------------------------------------------------------------------------
> > > -
> > > >  Kaustubh S. Phanse                                   kphanse@ee.vt.edu
> > > >  PhD student                                      http://www.ee.vt.edu/~kphanse
> > > >  Alexandria Research Institute
> > > >  Electrical & Computer Engineering Department
> > > >  Virginia Polytechnic Institute & State University
> > > >
> > > ----------------------------------------------------------------------------
> > > -
> > > >
> > > >
> > > >
> > >
> > >
> 
> --
> ----------------------------------------------------
> Paolo Molgora, NM System Team, Alcatel TSD Vimercate
> E-Mail: mailto: paolofranco.molgora@netit.alcatel.it
> Tel.: +39-039-686 4032 (or via Alcanet: 2 210 4032)
> Fax : +39-039-686 4185 (or via Alcanet: 2 210 4185)
> ----------------------------------------------------
> 
> 
> 
>