NFCC and MIP

1. NFCC and MIP Filtering Tunnels Considered Harmful

2. Background • Firewalls and MIP don’t play well together. • In NFCC, where clients update policy, clients carry the responsibility for ensuring correct MIP operation. • A sufficiently intelligent client can accomplish anything. • We want to make it easy for clients. • We make it easy by explicitly supporting certain topologies.

3. Guiding Principles • Nodes (or their proxies) are responsible for their own traffic. • Must support MIPv4 and MIPv6. • Must support asymmetric routing, route optimization and reverse tunneling. • Must support foreign agents and colocation. • Should support encrypted tunnels.

4. More Guiding Principles • MIP support should not make simple IP more complex (don’t let the tail wag the dog!). • NFCC may be present, but not assumed, in home and visited networks. • Simple MIP scenarios should be simple to implement. • MIP support must not reduce security.

5. Golden Rule: Don’t Filter Tunnels Tunnel Home Agent Foreign Agent Home NFCC Visited NFCC Node

6. Two NFCCs • Home NFCC responsible for filtering traffic into tunnel. • Home operator’s policy in home network. • Visited NFCC responsible for filtering traffic into visited network. • Visited operator’s policy in visited network. • Clear distinction of policy and trust. • Node responsible for managing both NFCCs (only one to manage for simple IP).

7. Special Case: Colocation • In colocation scenario, tunnel terminates inside visited NFCC. • This is OK so long as: • Operator of visited network is prepared to delegate trust to home network NFCC. • Operator of visited network allows such tunnels to traverse visited NFCC.

8. Conclusion • One simple assumption (don’t filter tunnels) allows all important MIP scenarios to be supported. • There is one special case: colocated addresses, which require trust to be delegated. • Requirements on NFCC clients are low impact (no heroic measures).