Subject: RE: [NSIS] An NSIS requirement with backing scenario

From: [email-masked]
Date: Thu, 14 Mar 2002 10:10:12 -0500

Hi Hannes:
 
Please see some comments below.

-----Original Message-----
From: ext Hannes Tschofenig [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 4:56 AM
To: Chaskar Hemant (NRC/Boston); [email-masked]
Subject: RE: [NSIS] An NSIS requirement with backing scenario

hi hemant!

> Hi:

> I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that 

> motivates such explicit requirement. I would like to know if WG deems this as an important issue.

> "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes".

i like this requirement. it think that it is a good idea to have this requirement. 

but: i think it is already covered with:

5.8.2 The QoS protocol must provide means to authorize resource requests

5.10.5 The QoS protocol should provide hooks for AAA protocols 

[HC] I think that only stating such requirements may not suffice. The document should elaborate on them and also give some exemplary scenarios. That helps to indicate where the deep waters are.

appart from the requirements for an interaction with AAA there are still open issues regarding billing/payment/charging 

as indicated below. there have been a number of papers describing different solutions 

but i do not know a satisfiable one. maybe we can discuss some of the issues at the ietf conference 

next week. 

[HC] Can you construct any more scenarios from those papers that may be relevant for such requirement? It will be good to know as many scenarios as possible before going into the solution phase.

to your scenario below: 

just to make sure: the main problem seems to be that user B has to give "something" to network N_B telling that user A is paying for

the reservation.  

[HC] Yes, that is right. 

if A is not willing to provide credentials then there is obvioulsy a problem but 

a could provide credentials without concerns about security. it only depends how these "credentials" look like. 

from my point of view this information should be exchanged before the actual qos reservation takes place since it 

is an application issue. hence the information should already be available at the qos-reservation start-up. 

> ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. 

> Note that N_B cannot bill A directly.

there has to be some agreement between providers otherwise this exchange will not work. 

> (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. 

> (This part has to be addressed by SIP and SDPng).

i agree with you. 

> (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. 

> This is the requirement that needs to be included in NSIS requirements document.

this is true. 

first, the qos signaling messages must be authenticated, integrity and replay protected. 

second, the qos protocol should be able to transport information exchanged with protocols executed before the 

qos protocol is triggered. 

[HC] Issues such as these will affect NSIS protocol design. That is the main message I would like to convey via this requirement/scenario.

Regards, Hemant

ciao

hannes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Tuesday, March 12, 2002 4:55 PM
To: [email-masked]
Subject: [NSIS] An NSIS requirement with backing scenario

Hi:

I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that motivates such explicit requirement. I would like to know if WG deems this as an important issue.
 
"QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes".
 
Scenario:
-----------
 
A and B are connected to the Internet on the two sides of the globe. A places call to B, and (say during SIP transactions) intimates to B that A will pay for the call. Paying for the call also means paying for QoS of the corresponding packet transport. B accepts A's proposal. The call happens to be of bidirectional traffic type. 
 
A sends signal to its access network N_A asking it to give certain QoS to packet stream from A -> B. A is a subscribed customer of N_A, so there are no apparent difficulties for N_A in checking A's credentials and in billing A. Also, network N_A may then take appropriate means to guarantee end-to-end QoS, may be based on SLAs with other providers and may be using some NSIS signaling.
 
For the packet path from B -> A, A does not know apriori as to how the path looks like. So, the QoS establishment for this path needs to be initiated from B's side. Now, B is not paying for QoS in its own access network N_B. Since, A has agreed to pay, A needs to provide some credentials to B which would be acceptable to N_B. There are two problems encountered here: i) Though A has agreed to pay, A may not be willing to provide credentials to end host B for security reasons, ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. Note that N_B cannot bill A directly.
 
The following things need to happen to make this call through. 
 
(i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. (This part has to be addressed by SIP and SDPng).
 
(ii)  NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. This is the requirement that needs to be included in NSIS requirements document.
 
BR,
Hemant

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 15 Mar 2002 11:35:53 +0100

hi hemant!

please see my comments below.

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
  Sent: Thursday, March 14, 2002 4:10 PM
  To: [email-masked]
  Subject: RE: [NSIS] An NSIS requirement with backing scenario

  Hi Hannes:

  -----Original Message-----
  From: ext Hannes Tschofenig [mailto:[email-masked]]
  Sent: Wednesday, March 13, 2002 4:56 AM
  To: Chaskar Hemant (NRC/Boston); [email-masked]
  Subject: RE: [NSIS] An NSIS requirement with backing scenario

  hi hemant!

  > I would like to place the following requirement on table for discussion
in WG. I have also provided a scenario below that

  > "QoS signaling protocol MUST interwork with AAA for QoS authorization
and accounting purposes".

  i like this requirement. it think that it is a good idea to have this
requirement.

  [HC] I think that only stating such requirements may not suffice. The
document should elaborate on them and also give some exemplary scenarios.
That helps to indicate where the deep waters are.

  [ht] i agree with you that sample scenarios are a helpful for avoiding
traps and to get more insights. however consider that it is definitely
difficult to cover all possible variations and ideas people have in mind for
accounting. if you have some more ideas for scenarios please let me know and
thank you for the scenario given in your previous mail.

  appart from the requirements for an interaction with AAA there are still
open issues regarding billing/payment/charging

  as indicated below. there have been a number of papers describing
different solutions

  but i do not know a satisfiable one. maybe we can discuss some of the
issues at the ietf conference

  next week.

  [HC] Can you construct any more scenarios from those papers that may be
relevant for such requirement? It will be good to know as many scenarios as
possible before going into the solution phase.

  [ht] there will be future version of the requirements document. i will
incorporate your suggestions into the next version. however it may also
possible that these scenarios fit much better in a framework document.

  to your scenario below:

  just to make sure: the main problem seems to be that user B has to give
"something" to network N_B telling that user A is paying for

  the reservation.

  [HC] Yes, that is right.

  if A is not willing to provide credentials then there is obvioulsy a
problem but

  a could provide credentials without concerns about security. it only
depends how these "credentials" look like.

  from my point of view this information should be exchanged before the
actual qos reservation takes place since it

  is an application issue. hence the information should already be available
at the qos-reservation start-up.

  > Note that N_B cannot bill A directly.

  there has to be some agreement between providers otherwise this exchange
will not work.

  > (i) SIP has to convey "intent" of A to pay for the call to B. A may also
expect in return the B's cost of access at N_B.

  i agree with you.

  this is true.

  first, the qos signaling messages must be authenticated, integrity and
replay protected.

  second, the qos protocol should be able to transport information exchanged
with protocols executed before the

  [HC] Issues such as these will affect NSIS protocol design. That is the
main message I would like to convey via this requirement/scenario.

  [ht] i  again agree with you. but i think that these issues are already
covered with the current requirements for interaction with other protocols
(for example aaa) and with the requirment for extensibility.

  This is true

  Regards, Hemant

  ciao

  hannes

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
    Sent: Tuesday, March 12, 2002 4:55 PM
    To: [email-masked]
    Subject: [NSIS] An NSIS requirement with backing scenario

    Hi:

    I would like to place the following requirement on table for discussion
in WG. I have also provided a scenario below that motivates such explicit
requirement. I would like to know if WG deems this as an important issue.

    "QoS signaling protocol MUST interwork with AAA for QoS authorization
and accounting purposes".

    Scenario:
    -----------

    A and B are connected to the Internet on the two sides of the globe. A
places call to B, and (say during SIP transactions) intimates to B that A
will pay for the call. Paying for the call also means paying for QoS of the
corresponding packet transport. B accepts A's proposal. The call happens to
be of bidirectional traffic type.

    A sends signal to its access network N_A asking it to give certain QoS
to packet stream from A -> B. A is a subscribed customer of N_A, so there
are no apparent difficulties for N_A in checking A's credentials and in
billing A. Also, network N_A may then take appropriate means to guarantee
end-to-end QoS, may be based on SLAs with other providers and may be using
some NSIS signaling.

    For the packet path from B -> A, A does not know apriori as to how the
path looks like. So, the QoS establishment for this path needs to be
initiated from B's side. Now, B is not paying for QoS in its own access
network N_B. Since, A has agreed to pay, A needs to provide some credentials
to B which would be acceptable to N_B. There are two problems encountered
here: i) Though A has agreed to pay, A may not be willing to provide
credentials to end host B for security reasons, ii) If A and N_B are in
different jurisdiction, whatever credentials A has to provide may not
satisfy N_B. Note that N_B cannot bill A directly.

    (i) SIP has to convey "intent" of A to pay for the call to B. A may also
expect in return the B's cost of access at N_B. (This part has to be
addressed by SIP and SDPng).

    (ii)  NSIS signaling needs to interwork with AAA so that it can reserve
and bill for QoS resources in N_B. This is the requirement that needs to be
included in NSIS requirements document.

    BR,
    Hemant