Subject: RE: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt

From: Pete McCann <[email-masked]>
Date: Tue, 1 Jul 2003 09:46:52 -0500

Hi, John,

I don't think it's too soon to start considering this sort of
interaction, especially because, as Hannes has indicated, there may be
some impact on the NSIS protocol itself.  Also, our hope is that we
can make use of an IETF-specified Diameter application for the
appropriate interfaces in the next release of 3GPP and 3GPP2
specifications, which means the sooner we can get started the better.

We certainly intend to continue the discussion with Hannes and others
on both the NSIS and AAA lists, as appropriate - hopefully the
bandwidth we use will be tolerated by those not directly interested in
the topic.

-Pete

[email-masked] writes:
 > Hi Pete,
 > 
 > Question for you - NSIS will obviously need some AAA interaction,
 > not just for QoS, but for middle box traversal (note, new NSIS
 > charter has been announced).
 > 
 > It might be interesting to discuss this work in both AAA & NSIS,
 > but my feeling is that the AAA WG already has a lot to do.  Perhaps
 > you could work with Hannes to incorporate aspects of the drafts
 > together.  
 > 
 > thanks,
 > John
 > 
 > > -----Original Message-----
 > > From: ext Pete McCann [mailto:[email-masked]]
 > > Sent: 26 June, 2003 23:20
 > > To: [email-masked]; [email-masked]
 > > Subject: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt
 > > 
 > > 
 > > 
 > > Hi,
 > > 
 > > We hope everyone who is interested in QoS/AAA has a chance to read the
 > > draft we have just submitted.
 > > 
 > > Our work is definitely related to the 2 drafts-tschofenig that have
 > > been posted on the NSIS group (apologies for not acknowledging this
 > > explicitly in the draft, but we found them only recently and are still
 > > reading them).  However, our work focuses more on the requirements for
 > > a AAA protocol rather than requirements for NSIS.  Also, we are trying
 > > to set forth in our draft what we think is the proper relationship
 > > between NSIS/RSVP, AAA, and call control protocols like SIP.
 > > 
 > > Please read/comment!
 > > 
 > > -Pete
 > > 
 > > [email-masked] writes:
 > >  > A New Internet-Draft is available from the on-line 
 > > Internet-Drafts directories.
 > >  > 
 > >  > 
 > >  > 	Title		: Requirements for a QoS AAA Protocol
 > >  > 	Author(s)	: F. Alfano et al.
 > >  > 	Filename	: draft-alfano-aaa-qosreq-00.txt
 > >  > 	Pages		: 16
 > >  > 	Date		: 2003-6-24
 > >  > 	
 > >  > This document describes requirements for a protocol that would 
 > >  > perform Authentication, Authorization, and Accounting for 
 > > Quality-of-
 > >  > Service reservations.  This protocol would be used by 
 > > elements along 
 > >  > the path of a given application flow to authenticate a reservation 
 > >  > request, ensure that the reservation is authorized, and to account 
 > >  > for resources used during the life of the application flow.  A QoS 
 > >  > AAA protocol should also support dynamic authorization of QoS as a 
 > >  > function of application and account state.  While we assume the 
 > >  > existence of some QoS reservation protocol to allow endpoints to 
 > >  > request QoS from network elements, complete requirements 
 > > for such a 
 > >  > protocol are outside the scope of this document and a QoS AAA 
 > >  > protocol could be used to support more than one kind of 
 > > reservation 
 > >  > protocol.  A QoS AAA protocol could be used between any 
 > > bearer-level 
 > >  > network element that lies along the path of an application 
 > > flow and 
 > >  > an application server that lies anywhere in the network, 
 > > allowing for 
 > >  > a wide variety of flexible service deployment models.
 > >  > 
 > >  > A URL for this Internet-Draft is:
 > >  > http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-00.txt
 > > 
 > > 
 > >

---

From: <[email-masked]>
Date: Wed, 2 Jul 2003 11:49:11 +0300

Hi Pete,

> bandwidth we use will be tolerated by those not directly interested in

I think if we breakdown the problem into near term and longer term,
the Diameter based solution is a good approach for the near term &
may help generate useful material for the longer-term impact on
NSIS.

I don't see a problem discussing this on NSIS.

thanks,
John

---

From: Pete McCann <[email-masked]>
Date: Wed, 2 Jul 2003 15:16:21 -0500

Tschofenig Hannes writes:
 > hi pete, 
 > 
 > as promised i have read your draft and provided some comments inline. please
 > take a look at: 
 > 
 > http://www.tschofenig.com/comments/draft-alfano-aaa-qosreq-00-hannes.txt
 > 
 > it is good that you join the discussion. 
 > 
 > ciao
 > hannes

Hi, Hannes,

Thanks for your detailed comments - unfortunately it is more difficult
for me to post files to the web on short notice, so I will try to respond to
each of your points in this e-mail, deleting most of the draft text.

See below...

# please see my comments inline. 

# general comment: 
# 
# it is good that someone finally joins the aaa/qos discussion. i
# always had the impression that there are a number of things that
# need to be discussed.

It's good to find your work in progress here in NSIS: hopefully we can work
together to produce something useful.

# Section 1 discusses a number of issues which are not applicable for
# AAA and QoS reservations (my opinion).

The Introduction tries to motivate the scope of the work; perhaps it wouldn't be
appropriate for the final requirements document, at least not in its current form.
(but see below)

# For the purpose of authorization it is not relevant which protocols
# (nsis, rsvp, etc.) carry the qos request to the network.

Yes, I agree - section 1 is just an introduction, and is an attempt to motivate
the work in the context of several different reservation protocols.  Note that
our draft is a set of requirements for a AAA protocol, not a set of requirements
for NSIS.

# it would be good to have the documents more generic, link layer and
# 3gpp (or similar) independent.

Understood; the 3G examples are given simply as motivation.  In
particular, we think that some of the current architectures for
authorizing QoS may be harmful, as they may tend to limit the
deployability of new services by linking the signaling plane to the
bearer plane in a certain inflexible way.  The body of the document
should be generic.

# the term bearer is not used in nsis. 

We use this to refer to anything that is on the path of the application flow
or to the resources used to support the application flow.  Can you suggest
the proper NSIS term?  I guess we are showing our bellhead colors here...

   there will be no need to manage them with a reservation protocol.  
   Also, if the transport or application layers can provide self-
   correcting congestion control, it may be possible to operate the 
   network even with high utilization and still meet the QoS 
   requirements of the various applications.

# this is a motiviation for not using qos at all. 

Yes, it's one scenario where you don't necessarily need to signal for
resources, and is designed to set up a contrast with the remainder of
the paragraph...

  However, when bandwidth is 
   expensive and must be carefully managed, such as in wide-area 
   cellular networks, and/or when applications and transport protocols 
   lack the capability or cannot be trusted to perform congestion 
   control, explicit reservation techniques are required.  Note that a 
   reservation protocol might be used regardless of the mechanisms used 
   to enforce QoS, e.g., IntSrv or DiffSrv. 

...
    
   Despite the advantages of closer coupling between application and 
   bearer, the use of private, local interfaces between SIP servers and 
   the bearer path leads to several disadvantages: 
    
      * Use of SIP servers other than the ones provided by the operator 
        becomes more difficult. 
      * Deployment of some new applications requires close coordination 
        with the network operator. 
      * It becomes impossible to handle mobility at the network layer 
        when a change in the bearer element point of attachment to the 
        Internet requires a change in the associated SIP server. 
      * Use of protocols other than SIP to establish sessions becomes 
        impossible. 
   
# I would like to understand the motivation for the tight 
# coupling between an application and a QoS signaling protocol. 

See the previous paragraphs in the draft; however, what is not covered
there explicitly is the desire on the part of operators to participate
in more than just transport of IP packets.  They do this by preventing
bearer application flows until some SIP server in their network says
it is OK.

Now, that may or may not be a good idea, but it seems to be a reality
of the current 3G architectures.  We think that by opening up a
QoS/AAA interface, and by doing this work in the IETF, we can at least
make sure that the interface between application and bearer is an
open, inter-domain one and allows for application servers to be placed
anywhere on the Internet, assuming they can connect to the AAA cloud.
That will allow for easy deployment of new applications, in keeping
with the end-to-end principle.

# - which application knowledge is sometimes needed 

Sometimes it is just the fact that some particular application server
participated in the call set-up.

# - the should be a clearer distinction between " the qos protocol
# obtains information from the application signaling protocol" and "tight coupling". 

We can work on this for the next version.

# - does this related a bit to john's draft draft-ietf-sipping-aaa-req-03.txt?

Only indirectly.  I think sipping-aaa is an attempt to capture the
requirements of a AAA protocol that would support SIP.  That is, you
need to authenticate & authorize registrations, INVITEs, etc.  In
contrast, we are proposing a AAA protocol that would be used to
authenticate QoS reservation requests.  Now, the reservation requests
may have been triggered after some SIP interaction took place, but
that is just happenstance --- in general there is no need to execute
SIP prior to a QoS reservation request.

...
 
   To meet the requirements of network operators while at the same time 
   preserving the best of the end-to-end Internet service model, we 
   propose that a AAA protocol be developed that can be used by bearer 
   elements to authenticate, authorize, and account for individual 
   application flows that require QoS.

# there is already a aaa protocol used for this purpose => 
#
#  [RFC2748]    Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, 
#  R., Sastry, A.: "The COPS(Common Open Policy Service) Protocol", RFC 
#  2748, January, 2000. 
#   
#  [RFC2749]    Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, 
#  R., Sastry, A.: "COPS usage for RSVP", RFC 2749, January, 2000. 
#   
#  [RFC2750]    Herzog, S.: "RSVP Extensions for Policy Control", RFC 
#  2750, January, 2000. 
#
# is this insufficient for your purpose? 

COPS is one approach, but my personal bias would be to do this sort of
thing with Diameter.  Mainly, this is because the 3GPP2 operators will
already have an inter-domain AAA infrastructure based on RADIUS
(hopefully evolving to Diameter) and it would be good to re-use this
infrastructure for QoS authorization as well as basic network access
authentication.  I don't mean to restart the COPS vs. Diameter thread
here, but I think Diameter has some advantages over COPS.

...

                          +------+         +------+ 
                          | Subs |         |      | 
                          |  DB  |         |  AS  | 
                          |      |         |      | 
                          +---\--+         +---/--+ 
                               \              / 
                                \            / 
                               /-\----------/\ 
                           ////               \\\\ 
                         ||                       || 
                        |         AAA Cloud         | 
                         ||                       || 
                           \\\\               //// 
                               \-------+-----/ 
                                       | 
                                   +---+--+ 
               Application         |      | 
               Flow ===============+  BE  +==========>> 
                                   |      | 
                                   +------+ 
             Figure 1.  An architecture supporting QoS-AAA 
    
   Figure 1 depicts a bearer element 

# why is it necessary to talk about bearer elements? 

These are the nodes that would process NSIS (or other reservation) messages, i.e.,
the IP routers along the path of the flow.

# what is the subs db? 

This is short for "Subscriber Database" --- it would be (or be
"behind") the home AAA server, and would store information about
the subscription, i.e., what sorts of QoS the user is allowed.

# what information is used to compute this authorization decision?

If the subscriber database is used, it might just be a check of the
requested QoS (and perhaps the link type and/or some other indication
of cost) against what the user has signed up for.

If an application server is used, it might be a check of the requested
QoS against the e.g., SIP SDP that was negotiated.

  In more complex deployment models, the 
   authorization will be based on dynamic application state, so the 
   request must be authenticated and authorized based on information 
   from one or more application servers.

# what information would you like to use to compute this authorization decision? 
# how does the message flow look like? 

We could get into that in a protocol document; I'm not sure it belongs
here in the requirements.  At a high level, I think the bearer element
would pick up the QoS request, and then send a AAA message to the
authorizing entity containing various parameters of the request.  The
authorizing entity would then consult internal data structures and return
a yea/nay response.  Also, the authorizing entity could update the bearer
element proactively if the subscriber profile changes or if the application
state changes.

  If defined properly, the 
   interface between the bearer element and AAA cloud would be identical 
   in both cases.

# the interface propably but the message routing seems to be more complex since
# some information from the application server needs be incorporated? 

I'm not sure it has to be.  Assuming there is an identifier for an "authorizing
entity" and that entity has the ability to update the bearer element dynamically,
we can really hide the details of what kind of authorizing entity is being used.
However, I think it's important to talk about application servers explicitly
in the requirements so that we know what role they will be playing in the overall
architecture.

...

    Termination Actions 
       On-line accounting allows for the on-line accounting 
       authorization entity to terminate flows in real time. A 
       termination action defines the action to be taken by the bearer 
       element for the case where a flow has been terminated. For 
       example flow packets might be dropped, might be redirected, or 
       might be allowed to continue but not be counted. 
    
# the term "On-line accounting" is new to me? is it something similar to real-time credit control?

Yes, also called "pre-paid."  We should be more explicit about that.

...

4.1 Identity Information 
    
   The QoS signaling protocol MUST carry information sufficient to 
   identify an authorizing entity for a QoS request. 
    
   For instance, the identity may be represented as the NAI of a user or 
   FQDN of an application server. 
   
# this requirement is already included in the nsis requirements draft. in section 
# 5.7.1 "Authentication of signaling requests" we require that the entity requesting resources 
# has to be authenticated. 

Ok, good.  Again, our document is intended to be a requirement for a
AAA protocol rather than NSIS, but we thought it was important to list
at least the basic attributes that must be supported by a reservation
protocol.  This sort of requirement may or may not go into a final
requirements document, depending on what the WG thinks.

4.2 Flow Information 
    
   The QoS signaling protocol MUST carry information sufficient to 
   identify the application flow(s).

# this is a natural requirement for qos signaling and therefore covered by the nsis requirements draft. 

Ok, good, but see above.

  However, the protocol MUST allow 
   flow information to be under-specified ("wild carded") in the case 
   when specific endpoints are not known at the time of resource 
   reservation. 

# this is a new requirement. why would you like to specify wildcards? 
# wildcards for what (ports, ip addresses, transport protocol; source or destination  ?
# that might raise a number of questions!

This is just an attempt to capture e.g., the wildcard sender selection
supported by RSVP.  Depending on the signaling protocol, the endpoint
may or may not have complete information about the sender IP
address/port, and may only have a range of destination
ports... anyway, we are open to re-wording this.

4.3 Authentication Information 

# the subsection title does not match the content

Could you be more specific?  Do you not think that checking the integrity of
a message is a form of authentication?
    
   The QoS signaling protocol MUST be integrity protected. 

# covered by requirement 5.7.3 Integrity protection

See above with respect to requirements on a generic reservation protocol
in this document.
    
   For example, each message could carry a cryptographic message 
   authentication code to ensure that only valid requests are granted by 
   the network.  This is especially important when a user is being held 
   responsible for charges associated with a QoS session.

# how would you enable that? "held responsible for charges" sounds like non-repudidation

I'm not sure we need a strong form of non-repudiation (really, that would
require MACs on every packet in the flow!) but at least we should have an
initial/periodic authenticated request.  

...

5.1 Inter-domain Support 
    
   The QoS AAA protocol MUST support inter-domain operation where the 
   bearer elements, subscriber databases, and application servers can 
   each belong to different administrative domains. 

# covered by the fact that mobility is a goal for nsis. 
# additionally we specified "5.9.4 SHOULD provide hooks for AAA protocols "

This one is important for the AAA protocol, and not necessarily covered by
the 2 NSIS requirements you quote.  It is possible to have a mobile-aware
NSIS that provides hooks for AAA, but where the supporting AAA infrastructure
does not support inter-domain operation.  This is a critical point that we
want to ensure is addressed by the AAA protocol.

...
    
5.2 Identity-based Routing 
    
   The QoS AAA protocol MUST route AAA requests to the authorizing 
   entity based on the identity information given in the QoS signaling 
   protocol. 

# this is the general procedure.     

Clearly, this requirement could easily be met by a Diameter or RADIUS
protocol, but I don't think its a "general procedure" of NSIS, right?

...
    
6.1 Authentication Check 
    
   The QoS AAA protocol MUST support verification of authentication 
   information present in QoS signaling messages. 
 
# should this requirement be combined with 4.1 and 4.3 of the previous section?

Again, this section covers the AAA protocol, whereas Section 4 covers
the QoS reservation protocol.

...    
    
7.1 Flow Information 
    
   The QoS AAA protocol MUST carry flow information to and from the 
   authorizing entity.

# is this a typo? how should the authorizing entity know information about the flow? 
# what whould the authorizing entity do with the flow information?
# between which entity is the flow information carried? 

The idea is to carry the flow information from the bearer element
(e.g., NSIS signaling-aware node) to the authorizing entity, so that
it can be matched against the application-layer signaling that was
carried out.  For example, if SIP is the upper layer signaling, and
the authorizing entity is a SIP server, you would check that the SDP
matched the flow requested in the NSIS signaling.

...

 However, the protocol MUST allow flow information 
   to be under-specified ("wild carded") in the case when specific 
   endpoints are not known at the time of initial resource 
   authorization. 
# hmm. i am not sure that i really understand what you really need this for.

See discussion above in section 4.  Maybe we need to re-state these requirments.

7.2 Application State Pointer 
 
   The QoS AAA protocol MUST carry information sufficient for an 
   application server to identify the appropriate application session. 
    
   Note that this requirement might be met by the same mechanism as for 
   requirement 7.1, if flow information alone is sufficient to identify 
   an application session. 

# nsis adds a session identifier? would that be useful?

An NSIS session identifier wouldn't necessarily help the authorizing entity
find the session information - it would be more like a token that would appear
separately in the NSIS signaling, and which would be carried via AAA to the
authorizing entity.

7.3 Dynamic Authorization 
    
   The QoS AAA protocol MUST support dynamic authorization; that is, it 
   MUST be possible to push updates towards the bearer element(s) from 
   authorizing entities. 
    
# what do you call "dynamic authorization"? 
# is a authorization request which is given an answer? 

The authorization state may change even after the initial (successful)
authorization.  For instance, if the user's subscription is updated to
remove QoS service, we may need to revoke an existing session.  Similarly,
if the application state changes, the corresponding QoS session may need
to be revoked.

   This requirement would support runtime changes to a subscriber 
   profile or application state transitions that would authorize/de-
   authorize application flows. 

# this sounds like assynchronous notifications from the user's home 
# network (in case of profile changes) to the networks where the user reserved 
# resources. 

Yes, exactly.

# what information is contained in the profile that would require such a notification?

For example, an upgrade/downgrade to a subscriber's allowed bandwidth.

...    
    
   The QoS AAA protocol MUST allow the authorizing entity to gate 
   authorized application flows. 
    
 # this sounds to me like an interworking with midcom. 
 # i would like to make sure that i correctly understood this issue: 
 # an unsuccessful qos authorization would cause packet filters to be installed that 
 # data traffic is disallowed to flow? 

At least, the packet filters would *not* be installed to support QoS for that flow.
Perhaps also the (best effort) packets would be discarded, but this is harder to
justify.

...

8.1 Accounting Records 
    
   The QoS AAA protocol MUST define QoS accounting records containing 
   duration or volume (bytecount) usage information, or both duration 
   and Volume usage information.  The records MUST also contain a 
   description of the QoS attributes (e.g., bandwidth, delay, loss rate) 
   that were supported for the flow. 
 
# this sounds like a useful requriement. haven't other groups (such as the 3gpp, packetcable or 3gpp)
# worked on similar things?

Yes, there are various accounting formats defined; hopefully the IETF could
define the generic "IP-layer" accounting for QoS that would be useful to a
wide variety of specific link layers.

8.2 Accounting Rules 
 
   The QoS AAA protocol MUST allow the authorizing entity to transfer 
   accounting rules that are applicable to specific flows. These rules 
   would define the on-line ("pre-paid") versus off-line ("post-paid") 
   nature of the accounting as well as convey other associated 
   parameters such as record identifiers, rating information, usage 
   quota, on-line termination actions, etc. 

# why would the authorizing entity exchange such rules? most information is 
# already available to the pep (such as flow identifier, qos objects, session id, etc.)

The rules are not what to do with the traffic; rather, they are how to
count the traffic.  For example, you should be told whether to count different
senders in distinct buckets, or count everything for a single reservation
together.  If pre-paid is used, you should be told how much quota is available
and in what units it is represented.  These all fall under the generic term
"Accounting Rules".  Perhaps we need to expand on these.

# why does accounting of qos differ so much from traditional accounting (except for some new 
# fields describing the qos parameters)?

Maybe it wouldn't, but at least pre-paid might have some impact over and above
"traditional" accounting (not sure which tradition you are making reference to,
of course).

   The QoS AAA protocol MUST allow for accounting rules to be provided 
   at authorization time as well as to be pushed later as dynamic 
   updates. 

# which protocol provides such a capability (radius, diameter, cops)? 

Again, our bias is towards Diameter, but you can clearly do this sort of
thing in both RADIUS and COPS with the right extensions/modifications.

8.3 Sending Accounting Records 
    
   The bearer element MUST send accounting records for a particular 
   application flow to the authorizing entity for that flow or to 
   another entity identified by the authorizing entity. 
 
# previously i had the impression that you would like to send an initial authorization request around. 
# this requirement, however, sounds like shipping accounting records around and asking for an authorization 
# based on these accounting record. 

It wasn't intended that way: this requirement simply requires accounting records
to be sent.  The destination for the accounting records depends on who authorized
the session.

8.4 Loss of Bearer Notification Requirements 
    
   The QoS AAA protocol MUST allow the bearer element to report loss of 
   bearer to the authorizing entity. 
    
# isn't it possible to specify this requirement as a "termination" reason. 

Yes, that might be a more generic way to put it.

# i guess a loss of bearer is more relevant for network access in general. 
# how do you detect a loss of bearer in general. some link layer mechanisms do not provide 
# such a mechanism.

Right, but this is a key requirement of some of the 3G deployments.  Cellular link
layers, especially when a voice call is ongoing, are very connection-oriented and
a loss of bearer indication is in fact available.

8.5 Accounting Correlation 
    
   The QoS AAA protocol MUST support the exchange of sufficient 
   information to allow for correlation between bearer accounting 
   records and application accounting records. 

# what type of information must be exchanged? 

Might just be the session ID / token I mentioned above.

...

9. Interaction with other AAA Applications 
    
   It is likely that an endpoint attached to a first-hop bearer element 
   was authenticated and authorized for basic, best-effort Internet 
   access prior to requesting any special QoS from the network.  If the 
   subscriber database for basic network access is the same as the one 
   containing a QoS subscription, it may be expeditious to define some 
   interactions between the AAA protocol used for basic access (e.g., 
   NASREQ [10]) and the one outlined here for QoS.  For example, it may 
   be useful to return some QoS-related attributes to the first-hop 
   bearer element at the time the endpoint is granted basic, best-effort 
   access.

# This is an often mentioned example. I am, however, not sure whether it is
# really useful. What it really make sense to send information like 
# 'user x is allowed to request max 5mbits for a duration of 10 min, then only 
# 3 mbits (but only during weekdays)' 
# what type of policies would you send around? 

The example you give actually sounds very similar to the pre-paid accounting
application being developed by 3GPP2!  There is a notion of a "Tariff Switch"
event that would happen at a given time-of-day, and this time is given to
the NAS when the user is authorized.  When the tariff switch occurs, the rating
for the call might change (i.e., 10c/minute before 7pm, 5c/minute after).

Anyway, it doesn't always have to be that complicated.  There might be a simple
profile like "this user is authorized for 2Mbit/sec when connecting via WLAN,
or 100kbit/sec when connecting via cdma2000".

# i often have the impression that this sounds great but has no
# practical value. i have also listed it in the aaa draft but later
# got the impression that this is the difficult to accomplish.

I wouldn't dismiss it so quickly.

# what information is stored in the user profile that could be used
# for this purpose?  is is desired by the user's home network provide
# to distribute this type of information?  this also assumes that the
# user profile is sort-of standardized. this is, however, not the
# case.

Home operators definitely will want to distribute such information.
We can help with the standardization here in the IETF.

...

   Also, it may be useful to allow application servers to push QoS 
   authorization information to a bearer element prior to any explicit 
   request from the endpoint.  This could support application endpoints 
   that do not support an explicit QoS signaling mechanism. In this 
   case, the authorization may be pushed via the home AAA server, which 
   presumably knows to which NAS the endpoint is currently attached.  
   Alternatively, the QoS AAA protocol may define some sort of 
   redirection facility that would allow application servers to send AAA 
   messages directly to selected bearer elements such as a NAS.  

# huch - that is certainly not easy to accomplish. there are a number
# of assumptions in there we need to be clarified.

Yes indeed - but I think it's clear that the Home AAA server that authorizes
basic IP access will have some information that could be made available to
other applications, especially if they are Diameter applications running on
the same server.

...
     
   The application endpoint makes a request for resources from the 
   bearer element.  The video server and the bearer element will verify 
   that the application endpoint has not requested more resources than 
   what were negotiated and for which the application has agreed to be 
   financially responsible.

# this bearer element is somewhat confusing. whatis the relationship between 
# the video server, application end point and bearer element?
# what is the trust relationship between these entities?

Sorry, terminology problem again.  Think of the bearer element as any
NSIS-aware IP router.  It has the same degree of trust as any IP
router between server and application endpoint.  In addition, it may
have a special relationship with the server (possibly via AAA brokers)
so that the server is allowed to authorize QoS sessions, even if the
subscriber's profile on its own wouldn't normally allow it.

...

11. Security Considerations 
    
   The QoS AAA protocol whose requirements are given in this draft 
   assumes that a security relationship exists between the authorizing 
   entity (the home AAA server or application server) and the bearer 
   element (AAA client).

# this is a rather strong assumption. that might not be true in all cases. 

It seems like precisely the relationship that is required: think about
it.  The bearer element is making a decision about whether to admit a
flow.  It consults an authorizing entity.  In order to trust the
result from the authorizing entity, there must be a (possibly
indirect) security relationship in place.

  This relationship implies that the bearer 
   element should grant service based on the say-so of the authorizing 
   entity, presumably because the used resources will be paid for in 
   some later settlement phase.

# payment is provided later only? 
# what about pre-paid cards which require real-time credit control. 

Yes, we should re-word it to allow that.

  The relationship may be direct or it 
   may be indirect via a AAA cloud consisting of brokers and proxies.  
   Each link in this chain of relationships MUST be secured to prevent 
   spoofed authorizations. 

# securing the aaa interaction does not prevent spoofing since the end point is authenticated. 
# is entity authentication between the user and the home network required with every qos reservation request?
# (or is data origin authentication sufficient?)

The security referenced here is between bearer element and authorizing entity,
possibly via AAA proxies.

To answer your question, yes, I think that if any AAA interaction is
done at a given NSIS node, then every QoS reservation should be
independently authenticated.

   The authentication outlined in Section 6 MUST be cryptographically 
   strong and protected against replay and other attacks. 
    
   Once QoS resources have been authorized, it may be possible for an 
   unauthorized party to subvert them for its own use.  Steps MUST be 
   taken to bind the authorization to the actual flow of packets using 
   the QoS bearer in the bearer element.

# this can actually only be prevented if the data traffic is cryptographically protected (either link layer or network layer 
# protection). do you mandate this?

No, I would not.  But we can at least make sure that the packets using the
QoS actually match the transport endpoints authorized by an application.

  Actual mechanisms applied to 
   the bearer traffic for this purpose might include, e.g., ingress 
   filtering and/or IPSec, but in general are beyond the scope of a QoS 
   AAA protocol. 
    
# ingress filtering does not prevent all attacks. 

No, but it would make the QoS reservation useless unless the spoofed
traffic was carrying the same source IP address/port.

-Pete