Implications of Trust Relationships for NSIS Signaling (draft-tschofenig-nsis-casp-midcom.txt) Authors: Hannes Tschofenig Henning Schulzrinne

Scope NSIS also aims to signaling non-QoS information Signaling NAT and firewall information is a possible NSIS application. Draft focus: Security issues for signaling in-path NAT/firewall information. Builds on previous TIST activities

Peer-to-Peer Security only Administrative Domain A Administrative Domain B Node ANode B Core Network Security protection between end hosts and networks depends on scenario (=> Secure Network Access)

Administrative Domain A Intra-domain Trust Relationship PDP Edge routers must receive particular attention Intra-domain signaling message protection is still required to “separated” NSIS nodes from non-NSIS nodes (by signaling message protection) Edge Router A Edge Router B Router

Administrative Domain B End-to-Middle Authentication Administrative Domain A Node ANode B Core Network In a firewall traversal environment user authentication might also be required to intermediate networks. Firewalls are distributed sparsely. User Credentials

Missing Trust Node ANode B Core Network Without protection of signaling messages between the two networks a signaling message exchange might not be possible. Alternatives: Authorization Tokens Signaling only at the local access network Receiver-initiated signaling No Trust / No Security Protection Administrative Domain B Administrative Domain A

Differences Difference QoS and Firewall signaling? Trust relationships and authorization are different For QoS signaling accounting and charging is a very important issue (for firewall signaling probably not) Firewall signaling is seen as more security sensitive Lower number of devices need to store state / are affected by a firewall signaling protocol (discovery)

Network Address Translation NAT handling Does not need to be combined within firewall signaling as an application. Must be addressed by NSIS to let the protocol operate correctly. Double-NAT handling makes a solution quite complex

Some IETF working groups also create protocols which allow firewall traversal or policy rule establishment: MIDCOM WG — Establishment of policy rules at middleboxes in an off-path nature IPSec WG — IPSec protocols would allow only authenticated data traffic to pass security gateways IPSRA WG — IPSec + legacy authentication + provisioning of configuration parameters. PANA — Secure network access based on EAP Additionally of interest: Authorization tokens exchanged with other protocols (e.g. HTTP or SIP) to restrict end host to create firewall rules Relationship to other protocols and working groups