Re: Policy control for RSVP

[Molgora Paolo <Paolo_Franco.Molgora@alcatel.it>]

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