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]