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

2. Hannes.Tschofenig@siemens.com 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

3. Hannes.Tschofenig@siemens.com 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)

4. Hannes.Tschofenig@siemens.com 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

5. Hannes.Tschofenig@siemens.com 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

6. Hannes.Tschofenig@siemens.com 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

7. Hannes.Tschofenig@siemens.com 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)

8. Hannes.Tschofenig@siemens.com 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

9. Hannes.Tschofenig@siemens.com 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