[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE:

hi felix!

>
>
> It depends on what are the security requirements and threats.
yes, this is always true. when looking at the threats for a qos signling
protocol it had two problems:
a) why do you really need end-to-end security if the protocol operates in a
hop-by-hop manner. i understand if someone mentiones the accounting issues
(who pays for what). but it is strange to introduce them all into a qos
signaling protocol since there are other protocols that have to executed
first in a typical application (i.e. rsvp or other qos signaling protocols
will not be send between the two endpoints without running other protocols
too - if used for end-to-end qos signaling).
b) the threat about a malicous qos (rsvp) aware node.
if an adversary manages to hack into a aaa, sip, etc. network element then
he is obviously able to do many actions. why should this be different for
rsvp (or other qos signaling protocols)? if an adversary is able to hack
into the pdp, into an edge router, etc. then he is able to mount all types
of attacks. who should this be prevented?
the only difference between rsvp and for example aaa or sip is the possibly
large number of nodes involved in the qos signaling. there is however an
architectural question whether this is really necessary/practical since
there are extensions that suggest that only the access network should store
per-flow information (i.e. run rsvp) and the core networks have aggregated
flows (trunks) for example based on diffserv. hence in practice the number
of nodes is not as large as it might look at the first sight.

additionally there is a strong desire to keep the latency (and bandwidth
consumption with signaling) low.

> In my opinion, RSVP security is really neither hop-by-hop nor
> end-to-end (or I should say it is a mixture of both).
it is definitely not end-to-end. with hop-by-hop you are right since there
are two integrity objects: one within the rsvp message part of the message
and the other one in the policy object. additionally there are credentials
in the policy object. furtheremore there are policy aware and policy unaware
nodes.

>
> Certain fields in RSVP are "mutable" (for example, maximum
> available bandwidth along the route path), and therefore, a
> pure end-to-end will not be possible. On the other hand, if
> we assume (i.e., our threat model) that an intermediate RSVP
> router (on the route path) can be malicious, then you need
> some forms of end-to-end to protect at least those "static"
> fields in an end-to-end fashion.
i agree with you. rsvp has mutable and non-mutable fields but they are not
labled as such (or there is no separation between mutable and non-mutalbe
fields). hence it is difficult to simply protect them by adding an other
"end-to-end integrity-object". additionally with this approach you obviously
introduce key management protocols which might be not too easy to solve
(establishing security associations between two arbitrary nodes turned out
to be difficult lacking a global pki, or aaa/kerberos, etc. infrastructure.

if some other protocols are executed before rsvp starts ( these protocols
have already allowed to figure out who will pay for what) then these
credentials (i call it opaque token) only need to be included into rsvp
without a need to add end-to-end security issues into rsvp itself and allow
other protocols to do that (e.g. sip). there is obviously a need to have a
interaction with other protocols including diameter (aaa in general) since
accounting records need to be produced and transmitted to the appropriate
locations.

>
> My students and I studied this problem a few years ago and the
> following is a web link to our paper:
>
> http://arqos.csc.ncsu.edu/papers/1999_10_iwqos99.pdf
>
> This work is somewhat old, but hopefully it will provide some
> information about the technical difficulties in dealing with
> RSVP security.
thanks. i read it some time ago. i do not remember it exactly but i think
you did not propose to use end-to-end security - it was more like a network
to network hop security using digital signatures.

ciao
hannes


> -Felix
>
>
> Hannes Tschofenig wrote:
> >
> > hi
> >
> > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp
> > capable router)?
> >
> > ciao
> > hannes
> >
> > > -----Original Message-----
> > > From: owner-ipsec@lists.tislabs.com
> > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins
> > > Sent: Saturday, May 25, 2002 5:01 AM
> > > To: SatishK Amara
> > > Cc: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group
> > > Subject: Re:
> > >
> > >
> > > Because IPsec is hop-by-hop but you want RSVP end-to-end.
> > >
> > > -derek
> > >
> > > SatishK Amara <kumar_amara@yahoo.com> writes:
> > >
> > > > Why don't you use IPSEC to secure RSVP.
> > > >
> > > > Satish Amara
> > > > --- Dong <dong_wei@tsinghua.com> wrote:
> > > > > Roy,
> > > > >
> > > > > I just read a paper "Preventing Denial of Service
> > > > > Attacks on Quality of Service", which is written by
> > > > > some guys from N.C. State university and UC Davis.
> > > > > The service quality to legimative users could be
> > > > > degraded by attacks on control flow or data flow.
> > > > > For example, an illegal user can forge a reservation
> > > > > message, so he can receive an unauthorized amount of
> > > > > resources. I just wanna to know what threats exist
> > > > > in providing QoS, and what the state-of-art
> > > > > techniques to prevent, detect and counter those
> > > > > attacks, and of course recovery mothods as well.
> > > > >
> > > > > Thx a lot.
> > > > >
> > > > > Dong
> > > > >
> > > > >
> > > > > Dong,
> > > > > Please be a little more precise in what you are
> > > > > asking for, i.e.
> > > > >
> > > > > 3-5 bullet list items on what kind of security you
> > > > > seek.
> > > > >
> > > > > Roy
> > > > >
> > > > > -----Original Message-----
> > > > > From: Dong [mailto:dong_wei@tsinghua.com]
> > > > > Sent: Thursday, May 23, 2002 2:05 PM
> > > > > To: Security_Area_Advisory_Group; IPsec
> > > > > Subject: Secure QoS
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I am trying to do a survey on Secure QoS. Any paper
> > > > > on that? Thx.
> > > > >
> > > > > Dong
> > > > >
> > > > >
> > > > _____________________________________________________________
> > > > > Get Tsinghua University free email account:
> > > > > www.tsinghua.com
> > > > > Web site sponsored and hosted by AtFreeWeb.com
> > > > >
> > > > >
> > > > >
> > > > >
> > > > _____________________________________________________________
> > > > > Get Tsinghua University free email account:
> > > > > www.tsinghua.com
> > > > > Web site sponsored and hosted by AtFreeWeb.com
> > > > >
> > > > >
> > > > _____________________________________________________________
> > > > > Promote your group and strengthen ties to your
> > > > > members with email@yourgroup.org by Everyone.net
> > > > http://www.everyone.net/?btn=tag
> > > >
> > > >
> > > > =====
> > > > In natural science, Nature has given us a world and we're just
> > > to discover its laws. In computers, we can stuff laws into it and
> > > create a world            -- Alan Kay
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > LAUNCH - Your Yahoo! Music Experience
> > > > http://launch.yahoo.com
> > >
> > > --
> > >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > >        Member, MIT Student Information Processing Board  (SIPB)
> > >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> > >        warlord@MIT.EDU                        PGP key available
>
> --
> ----------------------------------------------------------------------
> Dr. S. (Shyhtsun) Felix Wu                           wu@cs.ucdavis.edu
> Associate Professor                      http://www.cs.ucdavis.edu/~wu
> Computer Science Department                     office: 1-530-754-7070
> University of California at Davis               fax:    1-530-752-4767
> ----------------------------------------------------------------------