that offers QoS reservations (referred to as "service provider") and a third party that guarantees that the party making the reservation actually receives a financial compensation (referred to as "trusted third party").
In this context,"repudiation" refers to a problem where either the user or the service provider later deny the existence or some parameters (e.g., volume or price) of a QoS reservation towards the trusted third party. Problems stemming from a lack of non- repudiation appear in two forms:
Service provider's point-of-view: A user may deny having issued a reservation request for which it was charged. The service provider may then want to be able to prove that a particular user issued the reservation request in question.
User's point-of-view: A service provider may claim to have received a number of reservation requests from a particular user. The user in question may want to show that such reservation requests have never been issued and may want to see correct service usage records for a given set of QoS parameters.
In today's networks, non-repudiation is not provided. Therefore, it might be difficult to introduce with NSIS signaling. The user has to trust the network operator to meter the traffic correctly, to collect and merge accounting data, and to ensure that no unforeseen problems occur. If a signaling protocol with the non-repudiation property is desired for establishing QoS reservations, then it certainly impacts the protocol design.
Non-repudiation functionality places additional requirements on the security mechanisms. Thus, a solution would normally increase the overhead of a security solution. Threats related to missing non- repudiation are only considered relevant in certain specific scenarios and for specific NSLPs.
4.7. Malicious NSIS Entity
Network elements within a domain (intra-domain) experience a