![](bg9.png)
user authentication and authorization more closely with the QoS reservation
protocols. This would further increase the complexity of such protocols.
With the dependent approach, either the proxies can instruct the QoS
components to provide certain QoS features, or the QoS protocols would
carry the authorization tokens.
− Network security and translation service: For the case of traversing a
firewall, SIP independent authorization does not apply easily as controlling
the middle box requires knowledge about all the communicating end
systems. NAT traversal is not possible with the SIP independent scenario, as
the SIP proxy needs to know the results of the address translation of the
media flows already during the signalling phase.
− Connection services: For the case of gateway usage, using the SIP
dependent scenario is preferred. The SIP proxy provides a kind of a firewall
in front of the gateway filtering unauthorized requests and reducing the load
on the gateways that would have been otherwise required to authenticate
and authorize the users. The SIP independent scenario is applicable as well
but would require the user to authenticate himself directly with the gateway.
This would imply, that the gateway needs to maintain its own AAA
infrastructure and relation with the user.
− Security: This aspect indicates whether the used solution would have negative
effects on the security of the communication session or the signalling protocol.
Also we need to avoid introducing new possibilities for denial of service attacks
or data manipulation
− For a proxy to authorize a QoS reservation for example, it needs to extract the
media description data from the SIP messages and analyze them. This means
that SIP messages cannot use end-to-end encryption in the SIP dependent
scenario. This is not an issue for the SIP independent scenario.
− Another aspect is the security of the exchanged authorization token between
the proxy and the user in the user initiated scenario. This data usually
indicates the entity that generated the token as well as a special entry to the
authorization data generated at that entity during the SIP signalling. Stealing
this data could allow an interceptor to generate QoS requests under the
identity of the actual user involved in the SIP session establishment. As
described in Sec. 3.1.1, this can be avoided by encrypting the exchanged
tokens. Further, this risk can be reduced by indicating in the AAA entries
created during the session establishment phase the exact addresses of the
communicating entries. Thereby during the QoS reservation phase only
reservations between those addresses can be established. However, this still
allows for a denial of service attack. By sending data to the callee and putting
the IP address of the caller in the data packets an attacker can reduce the
share used by the actual caller of the QoS resources and thereby incur costs
on him for resources he did not use. To avoid this case, the communication
link between the proxy sending the authorization token and the end systems
needs to be secured. This involves establishing a shared key between the
involved entities and signing sent packets with this key, which further
complicates the session set-up and initial authentication procedures. Another
96