NSIS Authentication, Authorization and Accounting Issues

Download Report

Transcript NSIS Authentication, Authorization and Accounting Issues

NSIS Authentication, Authorization and
Accounting Issues
(draft-tschofenig-nsis-aaa-issues-00.txt)
Authors:
Hannes Tschofenig
Henning Schulzrinne
Maarten Buechli
Sven Van den Bosch
Draft Scope
This draft is:


A first attempt to describe AAA issues relevant for NSIS.
It points to the importance of authorization/charging for QoS
signaling.
The draft is not:



A summary of mathematical pricing models
A new protocol proposal
A motivation for a certain architecture
[email protected]
Introduction

At the last IETF Steve Bellovin talked about security issues in
NSIS.

He pointed to the importance of authorization for an NSIS
protocol.

An interesting aspect of authorization for QoS signaling is:
Authorization = ability to charge someone1
1 There are other authorization issues (e.g. session ownership).
[email protected]
Introduction (cont.)

Authorization has an implication on the security architecture.

We looked at two possible models:
— New Jersey Turnpike Model
— New Jersey Parkway Model
[email protected]
New Jersey Turnpike Model
Network A
Network B
Data
Sender
Node A
•
•
Network C
Data
Receiver
Node B
Peering relationship is used to provide charging between
neighboring networks
Similar to edge pricing proposed by Schenker et. al.
[email protected]
NJ Turnpike Model Issues

Establishment of the financial settlement between end host (data
sender favorable) and access network based on network access
procedure (not per-session based)

Simple (if data sender is charged for the reservation)

More difficult: receiver-initiated signaling and charging for data
receiver

Unfortunately it is possible to fully avoid reverse charging
(e.g. #800 numbers).
[email protected]
New Jersey Parkway Model
Network A
Network B
Network C
Direct AAA relationship to intermediate networks
Node A
•
•
Data
Sender
Data
Receiver
Node B
Financial settlement has to be provided on a per-session basis
More complex: financial settlement to intermediate networks required
(authentication alone is insufficient)
[email protected]
NJ Parkway Model Issues

Trusted third party might be required such as a clearing house since
intermediate networks have no direct relationship to end host
•
Financial settlement has to be provided on a per-session basis 
scalability and deployment problem
•
More flexible signaling protocol functionality required:
• A route change might require interaction with end host.
•
Signaling protocol might support the possibility for intermediate
networks to interact with the end host
•
Aggregation in the core network might be difficult to use if persession information is required for charging.
[email protected]
Who is charged for what?

Basic question: Charging for data sender or data receiver

Sender- vs. receiver oriented signaling adds some issues but is not
the source of the problem.

What is the problem?
Per-session based establishment of financial settlement
Example: Sender-initiated reservation with charging for data receiver
(see next slide)
[email protected]
Sender-initiated reservation with charging for data receiver
Network A
Network B
RESV
Network C
RESV
RESV
RESV
“Authorization Information”
Data
Sender
Node A
•
•
Data
Receiver
Node B
Node A indicates that some other entity is paying for the reservation.
Why should Network A authorize the reservation request?
[email protected]
Not enough problems already?
Price Distribution
Price for a QoS reservation:
 Price cannot be deferred from the destination IP address alone
(unlike telephone numbers)
 Price distribution required
(can be in-band, out-of-band or a combination of both)
 Price depends on the route
(number of traversed networks)
 Price is directional
(due to cost and route asymmetry)
An end user wants to know the price before issuing a reservation request.
[email protected]
Price distribution Building Blocks

A resource negotiation and pricing protocol (RNAP)

An embedded charging approach for RSVP

Border Pricing Protocol (BPP)

Billing Information Protocol (BIP)

Tariff Distribution Protocol (TDP)

Internet Open Trading Protocol (IOTP)

Open Settlement Protocol (OSP)
Not surprising: Many of these protocols require the same properties as a QoS
signaling protocol.
[email protected]
Conclusion

Peer-to-peer security is fine for a simple charging model (NJ
Turnpike). Authorization issues needs additional security protection.

Charging is not only an end-to-end (application) issue. The network
needs some information.

Some authorization/charging objects have to be included into a
NSIS protocol.

An NSIS protocol needs to be flexible. (e.g. support for several
roundtrips).
[email protected]