Subject: RE: Policy control for RSVP

From: Kaustubh Phanse <[email-masked]>
Date: Wed, 4 Jul 2001 16:35:47 -0400 (EDT)

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:[email-masked]]
> Sent: Monday, July 02, 2001 6:48 PM
> To: [email-masked]
> 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					  [email-masked]
> >  PhD student				       http://www.ee.vt.edu/~kphanse
> >  Alexandria Research Institute
> >  Electrical & Computer Engineering Department		               
> >  Virginia Polytechnic Institute & State University 
> >
> ----------------------------------------------------------------------------
> -
> > 
> > 
> > 
> 
>

---

From: Molgora Paolo <[email-masked]>
Date: Fri, 13 Jul 2001 16:26:00 +0200

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

--
----------------------------------------------------
Paolo Molgora, NM System Team, Alcatel TSD Vimercate
E-Mail: mailto: [email-masked]
Tel.: +39-039-686 4032 (or via Alcanet: 2 210 4032)
Fax : +39-039-686 4185 (or via Alcanet: 2 210 4185)
----------------------------------------------------

---

From: Kaustubh Phanse <[email-masked]>
Date: Fri, 13 Jul 2001 11:53:44 -0400 (EDT)

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 17 Jul 2001 13:31:51 +0200

# hi kaustubh, hi paolo!

# from a security perspective access control (access authorization) at the
first hop router is provided by
# a previous registration to the network e.g.
# - authentication at layer 2 e.g. as provided by wireless lan (via eap)
# - AAA (radius, diameter)

# this registration is finished before the actual qos signaling took place.
# furthermore there is the rsvp integrity object which provides host-based
# authentication.

# hence a denial of service attack is difficult if the sender of the rsvp
message is
# authenticated. every time a path or a rsvp message is sent from the user
to the first
# hop router a policy object should! be included to allow policy based
admission control. this allows
# authenticating the user at the pep or pdp, authorization of the request
# and possibly an accounting procedure to be triggered.

# in my opinion both the path and resv message (transmitted by the user's
host) should include a policy element.

# what do you think?

# ciao
# hannes

Hi! Paolo,

Thank you
regards
Kaustubh